Asp.Net MVC UNitOfWork und MySQL und Schlaf Anschlüsse

Question

Ich habe eine MVC Web-Anwendung, die auf die folgende Architektur

Asp.Net MVC2, Ninject, fliessend NHibernate, MySQL basiert, die eine Einheit von Arbeitsmuster verwendet.

Jede Verbindung zu MySQL erzeugt eine Schlafverbindung, die als ein Eintrag in den Ergebnissen der SHOW PROCESSLIST-Abfrage angesehen werden kann.

Schließlich werden so viele Verbindungen generiert, dass das App-Pool-Limit überschritten und die Web-App zum Absturz gebracht wird.

Ich vermute, dass die Verbindungen nicht richtig entsorgt werden.

Wenn dies der Fall ist, wo und wie soll das passieren?

Hier ist eine Momentaufnahme des Codes, die ich benutze:

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); 
    } 
} 

Answer 1

Ihr Beitrag gibt keine Informationen darüber, in welchem ​​Umfang UOWs erstellt werden.

Wenn es vorübergehend ist. Es wird überhaupt nicht entsorgt werden und das liegt bei Ihnen.

Im Fall von InRequestScope wird es entsorgt, nachdem der GC den HttpContext gesammelt hat. Aber wie ich Bob kürzlich in der Ninject Mailing List gesagt habe, ist es möglich, alle Objekte im Endanforderungs-Event-Handler der HttpApplication freizugeben. Ich werde dafür in der nächsten Version von Ninject Unterstützung hinzufügen.

Answer 2

Ninject nimmt keine Garantie darüber, wann und wo Ihre IDisposable s Dispose d sein wird.

Lesen dieses post from the original Ninject man

ich auch, einen Blick hier würde vorschlagen, dies für verschiedene Persistenzmechanismen und verschiedene Behälter kommen - das Wichtigste ist, Sie die Kontrolle übernehmen müssen und wissen, wann Sie Einhaken in der UOW Semantik Commit/Rollback/Dispose und überlasse es nicht dem Zufall oder dem Zufall (obwohl Convention großartig ist).

Answer 3

Ich habe einige Untersuchungen über die Ursache dieses Problems durchgeführt. Hier ist ein bisschen mehr Informationen und mögliche Lösungen:

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

Genießen.