Mam dość dużą aplikację sieci Web korzystającą z LINQ-TO-SQL działającą na platformie Azure i doświadczam przejściowych błędów z SQL-Azure, w związku z czym muszę wdrożyć ponowne próby. Jestem świadomy Transient Fault Handling Framework i kilku miejsc, które dają przykłady, jak go używać, ale wygląda na to trzeba owinąć każdy zapytań LINQ w coś podobnego do tego:Ponów logikę dla LINQ-TO-SQL na SQL Azure - Wydajne implementacje?
RetryPolicy retry = new RetryPolicy<MyRetryStrategy>(5, TimeSpan.FromSeconds(5));
Result = retry.ExecuteAction(() =>
{
… LINQ query here...
});
z setkami zapytań LINQ w mojej warstwie danych wydaje się to naprawdę nieładne, a także fakt, że wiele razy zapytanie nie jest faktycznie wykonywane, dopóki wyniki nie zostaną wyliczone. Na przykład większość moich funkcji w mojej warstwie danych zwraca warstwę IQueryable <> do warstwy biznesowej (co czyni je bardziej elastycznymi niż przywracanie listy). Oznaczałoby to, że musisz zaśmiecić warstwę logiki biznesowej za pomocą logiki bazy danych - brzydka.
Sądzę więc, że aby zachować logikę ponowną w warstwie danych, musiałbym wstawić .ToList() do wszystkich moich zapytań, więc są one wykonywane bezpośrednio, a nie w powyższej warstwie.
Naprawdę szkoda, że nie było sposobu implementacji logiki ponownej w niektórych klasach bazowych i nie trzeba zmieniać wszystkich moich zapytań. Wygląda na to, że EF również będzie miał ten problem.
Czy to jest prawdziwa odpowiedź, aby spróbować i porozmawiać z zespołem SQL-Azure o automatycznych próbach, więc nie musimy się tym martwić w naszym kodzie?
To trochę pomaga, ale czy nadal nie powinienem się martwić o zapytania, które faktycznie nie zostaną wykonane później w kodzie, w którym są wyliczane? Dlatego musiałbym naprawdę zbadać każde zapytanie i dowiedzieć się, gdzie faktycznie jest wywoływana baza danych. – PeteShack
Przepraszam, nie rozumiem cię bardzo dobrze. Czy masz na myśli, że martwisz się, jeśli coś pójdzie nie tak, będzie trudniej znaleźć źródło problemu, ponieważ zawijam zapytanie wewnątrz struktury próbnej? W tym przypadku chciałbym zaproponować, aby ustawić punkt przerwania na ponowną próbę.ExecuteAction i przejść przez kod. –
Nie, po prostu dodawanie logiki ponownej próby do istniejącej aplikacji zawierającej setki zapytań będzie trudnym zadaniem - głównie dlatego, że wywołanie bazy danych niekoniecznie musi się zdarzyć w kwerendzie linq-sql w warstwie danych. Wykonanie kwerendy może być opóźnione do momentu, gdy IQueryable zostanie faktycznie wyliczone - co może się zdarzyć w warstwie biznesowej. Po prostu nie wydaje się być czystym rozwiązaniem tego problemu. – PeteShack