2015-02-22 13 views
16

Po trzech godzinach debugowania i wyszukiwania mam nadzieję, że ktoś tutaj ma odpowiedź. Entity Framework (używając MySQL) zgłasza następujący wyjątek, jeśli szybko wywołuję następującą funkcję kolejno (np. < w odstępie 0,1 sekundy).Entity Framework "Niespodziewany stan połączenia" Wyjątek

System.InvalidOperationException: nieoczekiwany stan połączenia. Podczas korzystania z dostawcy pakowania upewnij się, że zdarzenie StateChange jest zaimplementowane na opakowanym DbConnection.

Jednak czasami funkcja działa bez żadnych problemów. Wyjątkiem jest wyrzucane na pierwszym ToList() rozmowy:

void InsertOrUpdateMaterials(List<Material> materials) 
{ 
    var id = GetUserId(); 
    var materialIds = materials.Select(x => x.MaterialId).ToList(); 

    // Remove old materials from DB 
    var oldMaterials = Db.Materials.Where(p => p.CreatedBy == id && 
      materialIds.Contains(p.MaterialId)).ToList(); // exception 
    Db.Materials.RemoveRange(oldMaterials); 
    Db.SaveChanges(); 

    // Replace previous materials with the new ones in list 
    Db.Materials.AddRange(materials); 
    Db.SaveChanges(); 
} 

dziwne, nigdy ten błąd wystąpił na serwerze rozwoju, więc zajrzałem do możliwych problemów konfiguracyjnych bezskutecznie.

Czasami Entity Framework rzuca:

System.Data.Entity.Core.EntityCommandExecutionException: Jest już otwarty DataReader skojarzony z tym połączeniem, które muszą najpierw zostać zamknięte.

Ponownie wskazując na wywołanie ToList(). Jakieś pomysły?

+4

Pomocne byłoby sprawdzenie, skąd pochodzi 'Db'. Domyślam się, że tak naprawdę mówi prawdę - pomiędzy otwarciem początkowego połączenia na Db, a wykonaniem 'ToList' (dostaniesz tutaj wyjątek, ponieważ to jest, gdy zapytanie jest" zmaterializowane "względem bazy danych) stan połączenia zmienił (zamknięty, itp.). EF sugeruje, że powinieneś posługiwać się 'StateChange', aby sobie z tym poradzić (np. Otworzyć ponownie połączenie lub cokolwiek innego) –

+6

Twój komentarz pomógł mi znaleźć rozwiązanie! Dziękuję Panu!! Spojrzałem na to, skąd pochodzi Db, a kontekst został zbuforowany. Za każdym razem zainicjowałem nowy kontekst i problem został rozwiązany. Naprawdę zaskakujące, jak pozwoliłem temu się ześlizgnąć. – arao6

+3

@ arao6 care, aby napisać bardziej szczegółową odpowiedź? FYI możesz napisać odpowiedź na własne pytanie w StackOverflow. I, FWIW, prawdopodobnie go przegłosuję :) – knocte

Odpowiedz

4

Dla innych osób, które mogą mieć podobny problem. W oparciu o powyższe komentarze wydaje się, że kod używa buforowanego kontekstu db. Po utworzeniu kontekstu db zostało zerwane połączenie db (w aplikacji nie zainstalowano programu obsługi StateChange). Po awarii połączenia aplikacja użyła buforowanego kontekstu db, aby wykonać niektóre operacje na nim.

Utworzenie nowego kontekstu db rozwiązało problem.

0

Miałem ten problem z Effort.EF6 1.3.0. Naprawiono dla mnie aktualizację zależności NMemory od wersji 1.1.0 do wersji 1.1.2.

+0

Wciąż otrzymuję błąd z NMemory 1.1.2. – Roger

+0

Czy widzisz ten sam problem z równoległością, co https://stackoverflow.com/a/47862865? – user326608

+1

Nie jestem pewien, używam NUnit 3.7. Naprawiłem problem zmieniając sposób, w jaki mój DbContext był obsługiwany, jak sugerował @Stephen Byrne. – Roger

0

Miałem ten sam problem, używając Effort.EF6, ale aktualizacja NMemory (jako sugerowana user326608) nie pomogła. Okazuje się, że XUnit is executing tests in parallel by default since V2.

Wyłączenie tego zachowania naprawiło to za mnie. Dodaj poniższe do AssemblyInfo.cs:

using Xunit; 
[assembly: CollectionBehavior(CollectionBehavior.CollectionPerAssembly)] 

Chociaż postrzegam to jako obejście, ponieważ testy jednostkowe powinny być niezależne od siebie.

Powiązane problemy