Asp.Net MVC UNitOfWork и MySQL и спящие соединения - PullRequest
5 голосов
/ 05 ноября 2010

У меня есть веб-приложение MVC, основанное на следующей архитектуре

Asp.Net MVC2, Ninject, Fluent NHibernate, MySQL, в котором используется шаблон единицы работы.

Каждое подключение кMySQL генерирует неактивное соединение, которое можно рассматривать как запись в результатах запроса SHOW PROCESSLIST.

В конечном итоге это приведет к появлению достаточного количества соединений, чтобы превысить лимит пула приложений и завершить работу веб-приложения.

IПодозреваю, что соединения расположены неправильно.

Если это тот случай, когда и как это должно происходить?

Вот снимок кода, который я использую:

public class UnitOfWork : IUnitOfWork
{
    private readonly ISessionFactory _sessionFactory;
    private readonly ITransaction _transaction;
    public ISession Session { get; private set; }

    public UnitOfWork(ISessionFactory sessionFactory)
    {
        _sessionFactory = sessionFactory;
        Session = _sessionFactory.OpenSession();
        Session.FlushMode = FlushMode.Auto;
        _transaction = Session.BeginTransaction(IsolationLevel.ReadCommitted);
    }

    public void Dispose()
    {
        if (Session != null)
        {
            if (Session.IsOpen)
            {
                Session.Close();
                Session = null;
            }
        }
    }

    public void Commit()
    {
        if (!_transaction.IsActive)
        {
            throw new InvalidOperationException("No active transation");
        }
        _transaction.Commit();
        Dispose();
    }

    public void Rollback()
    {
        if (_transaction.IsActive)
        {
            _transaction.Rollback();
        }
    }
}




public interface IUnitOfWork : IDisposable
{
    void Commit();
    void Rollback();
}




public class DataService
{
    int WebsiteId = Convert.ToInt32(ConfigurationManager.AppSettings["Id"]);

    private readonly IKeyedRepository<int, Page> pageRepository;
    private readonly IUnitOfWork unitOfWork;

    public PageService Pages { get; private set; }


    public DataService(IKeyedRepository<int, Page> pageRepository,
        IUnitOfWork unitOfWork)
    {
        this.pageRepository = pageRepository;
        this.unitOfWork = unitOfWork;

        Pages = new PageService(pageRepository);

    }

    public void Commit()
    {
        unitOfWork.Commit();
    }

}


public class PageService
{
    private readonly IKeyedRepository<int, Page> _pageRepository;
    private readonly PageValidator _pageValidation;

    public PageService(IKeyedRepository<int, Page> pageRepository)
    {
        _pageRepository = pageRepository;
        _pageValidation = new PageValidator(pageRepository);
    }

    public IList<Page> All()
    {
        return _pageRepository.All().ToList();
    }

    public Page FindBy(int id)
    {
        return _pageRepository.FindBy(id);
    }
}

Ответы [ 3 ]

3 голосов
/ 15 ноября 2010

Ваш пост не дает никакой информации, в какой области создаются UoW.

Если это переходный процесс.Он не будет утилизирован вообще, и это зависит от вас.

В случае InRequestScope он будет утилизирован после того, как GC соберет HttpContext.Но, как я недавно сказал Бобу в Ninject Mailing List , можно освободить все объекты в обработчике события конечного запроса HttpApplication.Я добавлю поддержку для этого в следующем выпуске Ninject.

2 голосов
/ 19 ноября 2010

Я провел некоторое исследование причины этой проблемы.Вот немного больше информации и возможных решений:

http://blog.bobcravens.com/2010/11/using-ninject-to-manage-critical-resources/

Наслаждайтесь.

0 голосов
/ 05 ноября 2010

Ninject не дает никаких гарантий относительно того, когда и где ваши IDisposable s будут Dispose d.

Прочитайте эту публикацию от оригинального Ninject man

IТакже я бы посоветовал осмотреться здесь, это подходит для различных механизмов персистентности и различных контейнеров - главное, что вам нужно взять под контроль и знать, когда вы цепляетесь в семантике коммитов / откатов / утилизации UOW и не уходитеэто случайно или совпадение (хотя Конвенция велика).

...