2012-09-25 18 views
11

Po prostu chciałem uruchomić to przez was wszystkich, aby sprawdzić, czy są jakieś jasne pomysły, ponieważ wyczerpałem wszystkie moje pomysły po całym dniu, nocy i poranku poszukiwań. Problemy, które napotykamy, niezmiennie koncentrują się na łączności z bazami danych, gdy są używane jednocześnie (test selenu), np. limity czasu, zrzucone/zamknięte połączenia, serwer bazy danych nieosiągalny.Problemy z równoczesnym korzystaniem z bazy danych Azure

Problem wydaje się być ograniczony do platformy Azure, ponieważ problem nie został jeszcze rozwiązany lokalnie, nawet podczas uruchamiania tego samego testu selenu na tym samym kodzie, wskazując na tę samą bazę danych (SQL Azure), aby wskazywać, że jest problem związany z łącznością wychodzącej bazy danych w SQL Azure. Do tej pory staraliśmy następujące:

  1. Azure obsługę przemijające uszkodzenia - Musimy powtórzyć logiki w miejscu gdy jest to chwilowy problem z usługą SQL Azure samego.
  2. Zmień protokół komunikacji - wypróbowaliśmy zarówno TCP, jak i nazwane potoki i napotkaliśmy ten sam problem z oboma.
  3. Dostosuj interwał limitu czasu połączenia z bazą danych - próbowaliśmy zwiększyć wartość .
  4. Dodawanie wielu aktywnych zestawów wyników - Dodaliśmy to do ciągu połączenia bez rezultatu.
  5. Sprawdzanie stanu połączenia dla każdego zapytania - Kiedy zwracamy dane DataContext , sprawdzamy jego połączenie i, w razie potrzeby, ponownie je otwieramy.
  6. Wyłączono buforowanie połączeń - podjęliśmy również próbę tego bez powodzenia .
  7. Zmieniono wzornictwo - Wybraliśmy się nawet do długości realizacji jednostka wzorca projektowego pracy, gdzie połączenia bazodanowe były wyrzuceniu się i wyrzucać po każdej jednostce pracy, ale to spowodował problemy gdzie indziej z leniwe załadunku , przekazywanie obiektów do metod i byłby to zbyt duży przerób w punkcie .

  8. Zmień rozmiar rola - Ostatnią rzeczą, jaką mogę myśleć, aby spróbować to się wielkością rola w razie jakichkolwiek ukrytych ograniczeń połączeń w systemie Windows Azure - to obecnie rozmieszczanie więc jest jeszcze cień szansy, że może działać!

Infrastruktura strona jest w następujący sposób:

  • klasy DataContext (rozciąga DbContext), która jest kod Pierwszy EF kontekst.
  • Klasa BusinessLayer zawiera prywatny, niestatyczny DataContext. DataContext jest konstruktorem wstrzykniętym do każdej klasy Manager/Helper.
  • Klasa BusinessLayerService zawiera publiczną, wątkową instancję klasy BusinessLayer .
  • Witryna MVC korzysta z BusinessLayerService.Instance w celu uzyskania dostępu do klas menedżera , które odczytują i aktualizują DataContext, które zostały przekazane.

Każda pomoc zostanie bardzo doceniona.

UPDATE: Mamy podniósł rozmiar VM dla średnich i wszystko to miało oznaczać, że był taki sam problem występuje trwało dłużej.

Kiedy kwestie zaczął zachodzącą, członek zespołu zauważyć wystąpił następujący wyjątek:

InvalidOperationException: Wykonanie polecenia wymaga otwartego i dostępnego połączenia. Aktualny stan połączenia jest uszkodzony.

To zaczęło zachodzącą gdy baza danych została uderzeniem (nie było charakterystyczne dla pewnego obszaru kodu).

+1

Doskonałe pytanie. +1 –

+0

Czy próbowałeś z klasycznym podejściem ADO.Net zamiast EF? Powiedziano mi, że ludzie mieli więcej problemów z EF niż ADO.Net podczas pracy z SQL Azure. –

+1

@GauravMantri Problem polega na tym, że w tej i wielu innych projektach, które mamy już na wolności, wszystkie używają EF, więc przejście na ADO.NET byłoby czasochłonnym i kosztownym procesem :) – mattytommo

Odpowiedz

5

Zetknąłem się z tego rodzaju problemem wcześniej. W moim przypadku miało to związek z niewłaściwą utylizacją Entity Framework ObjectContexts, zanim ostatecznie zbyt wiele kontekstów zostało odwróconych, a strona przewróciła się. Zidentyfikowaliśmy za pomocą programu Entity Framework Profiler, że podczas zgłaszania błędów istniało wiele niezamkniętych ObjectContextów.

Nie było możliwe, abyśmy przenieśli się do wzorca projektowego Jednostki Pracy (lub podobnego), ponieważ wymagałoby to przepisania warstwy biznesowej, dlatego rozwiązaliśmy to przez ręczne zamykanie obiektów ObjectContext po każdym żądaniu strony . Przyjęliśmy podejście ręcznego ręcznego ręcznego usuwania kontekstu w zdarzeniu End Request firmy Global.asax, jednak innym ważnym podejściem byłoby przechowywanie kontekstu w HttpContext lub implementowanie kontenera IoC (takiego jak Castle Windsor) za pomocą "żądania" " styl życia.