Negli ultimi giorni, stiamo registrando diverse eccezioni generate da Entity Framework (versione 6) sul nostro live stage, che si verificano solo occasionalmente e mostrano messaggi di errore, che riguardano tutti la connessione al database.
Non è consentito modificare la proprietà 'ConnectionString'. Lo stato attuale della connessione è chiuso.
Il contesto non può essere utilizzato durante la creazione del modello. Questa eccezione può essere generata se il contesto viene utilizzato all'interno del metodo OnModelCreating o se la stessa istanza di contesto è accessibile da più thread contemporaneamente. Si noti che i membri dell'istanza di DbContext e le classi correlate non sono garantiti come thread-safe.
Stato di connessione imprevisto. Quando si utilizza un provider wrapping, assicurarsi che l'evento StateChange sia implementato sul DbConnection spostato.
Il provider sottostante non è riuscito in Open.
Non possiamo ricordare che abbiamo cambiato nulla e come già detto questi errori si verificano solo a volte. Non possiamo riprodurli sul palcoscenico locale.
Qualcuno ha un'idea di cosa sta andando storto o di come indagare?
Modifica: è un'applicazione ASP.NET MVC 5 che utilizza Unity IoC per l'istanziazione. Usiamo un PerRequestLifeTimeManager auto-scritto che gira perfettamente liscio in altre applicazioni mvc.
Grazie al suggerimento di @Gerd Arnold e @Chris Pratt sono stato in grado di capire la causa principale del mio problema.
Effettivamente le eccezioni dovute a un'istanza di DbContext che è stata utilizzata contemporaneamente in più richieste. Questo DbContext fa parte di un servizio che viene iniettato dall'iniezione di proprietà Unity in un filtro di azioni. Quello che ancora non sapevo è che i filtri di azione non vengono istanziati per richiesta in APS.NET MVC ma vengono memorizzati nella cache e riutilizzati. Quindi non iniettare istanze di classi basate su DbContext o DbContext in filtri azione!
Abbiamo risolto il problema chiamando DependencyResolver.Current.GetService<ClassType>()
invece di utilizzare Dependency
-attribute nel codice del nostro filtro per ottenere un'istanza della rispettiva dipendenza (si noti che si perde la verificabilità del filtro attraverso questa soluzione alternativa)
Mi ci sono volute molte ore per trovare la soluzione. Agli utenti che occasionalmente incontrano gli stessi errori menzionati nella mia domanda, raccomanderei di verificare la propria app per tutte le classi basate su DbContext che potrebbero essere utilizzate contemporaneamente su richieste / thread.