2017-02-13 3 views
-1

In den letzten paar Tagen verzeichnen wir verschiedene Exceptions, die von Entity Framework (Version 6) auf unserer Live-Plattform geworfen werden, die nur gelegentlich auftreten und Fehlermeldungen, die alle auf die Datenbank bezogen sind Verbindung.Entity Framework: Verschiedene Verbindungsprobleme treten gelegentlich auf

  • Nicht Eigenschaft des 'Connectionstring' zu ändern erlaubt. Der aktuelle Zustand der Verbindung ist ist geschlossen.

  • Der Kontext kann nicht verwendet werden, während das Modell erstellt wird. Diese Ausnahme kann ausgelöst werden, wenn der Kontext in der OnModelCreating-Methode verwendet wird oder wenn auf die gleiche Kontextinstanz von gleichzeitig mehrere Threads zugegriffen wird. Beachten Sie, dass Instanzmitglieder von DbContext und zugehörigen Klassen nicht garantiert Thread-sicher sind.

  • Unerwarteter Verbindungsstatus. Wenn Sie einen Wrapping-Provider verwenden, stellen Sie sicher, dass das StateChange-Ereignis für die umgebrochene DbConnection implementiert ist ( ).

  • Der zugrunde liegende Provider ist bei Open fehlgeschlagen.

Wir können nicht vergessen, dass wir etwas und wie schon gesagt diese Fehler nur manchmal auftreten geändert haben. Wir können sie nicht auf lokaler Bühne reproduzieren.

Hat jemand eine Idee, was schief läuft oder wie zu untersuchen?

Bearbeiten: Es ist eine ASP.NET MVC 5-Anwendung, die Unity IoC für Instanziierung verwendet. Wir verwenden einen selbstgeschriebenen PerRequestLifeTimeManager, der in anderen mvc-Anwendungen absolut flüssig läuft.

+0

Können Sie das Stück Code teilen, wo Sie diesen Fehler sehen? Konnten Sie ein Muster oder einen Anwendungsfall identifizieren, in dem der Fehler auftritt? Verfügen Sie über Anwendungsprotokolle, die angeben können, bei welcher Codezeile die Ausnahme ausgelöst wird? –

+1

Ich bin mir ziemlich sicher, dass Sie Kontexte falsch verwenden. Wahrscheinlich als statische Mitglieder, aber sicher so, dass sie für mehrere Threads zugänglich sind. Refactoring Zeit! –

+1

Es ist unmöglich, ohne Code zu sagen. Ich stimme jedoch @GertArnold zu. Sie sollten eine und nur eine Kontextinstanz pro Anfrage haben. Wenn Sie mehrere Instanzen pro Anfrage neu erstellen oder umgekehrt statisch oder als Singleton usw. verwenden, haben Sie Probleme. –

Antwort

1

Dank der Andeutung von @Gerd Arnold und @Chris Pratt konnte ich die Ursache meines Problems herausfinden.

In der Tat wurden die Ausnahmen durch eine Instanz von DbContext verursacht, die gleichzeitig über mehrere Anfragen verwendet wurde. Dieser DbContext ist Teil eines Dienstes, der von der Unity-Eigenschaft injection in einen Aktionsfilter injiziert wird. Was ich noch nicht wusste, ist, dass Aktionsfilter nicht pro Anfrage in APS.NET MVC instanziiert werden, sondern zwischengespeichert und wiederverwendet werden. Also injiziere keine Instanzen von DbContext oder DbContext-basierten Klassen in Aktionsfilter!

Ich löste dieses Problem, indem DependencyResolver.Current.GetService<ClassType>() statt mit Dependency -Attribut in unserem Filter Code Aufruf eine Instanz der jeweiligen Abhängigkeit (Bitte beachten Sie, dass Sie die Testbarkeit des Filters durch diese Abhilfe verlieren)

Es zu bekommen Ich brauchte viele Stunden um die Lösung zu finden. Für diejenigen Benutzer, die gelegentlich die gleichen Fehler wie in meiner Frage auftreten, würde ich empfehlen, Ihre Anwendung für alle DbContext-basierten Klassen zu überprüfen, die möglicherweise gleichzeitig über Anfragen/Threads verwendet werden.

  1. Überprüfen Sie Ihre Unity IoC Regeln
  2. Geben Sie für Klassen, die durch IoC werden nicht instanziiert sondern könnte gleichzeitig verwendet werden.
  3. Überprüfen Sie alle Schritte entlang der MVC request lifecycle