Logika ponownej próby SQL Azure Database

Question

Zaimplementowałem następujący kod obsługi operacji logicznej INSERT/UPDATE z wykładniczym wycofaniem podczas zapisu do bazy danych Azure.

static SqlConnection TryOpen(this SqlConnection connection) 
{ 
    int attempts = 0; 
    while (attempts < 5) 
    { 
    try 
    { 
     if (attempts > 0) 
     System.Threading.Thread.Sleep(((int)Math.Pow(3, attempts)) * 1000); 
     connection.Open(); 
     return connection; 
    } 
    catch { } 
    attempts++; 
    } 
    throw new Exception("Unable to obtain a connection to SQL Server or SQL Azure."); 
} 

Jednak czy powinienem rozważyć zastosowanie logiki ponownej dla odczytów z mojej bazy danych? A może wystarczy metoda SqlCommand.CommandTimeout()? Większość moich odczytów są ustanowione za pomocą następującego kodu:

Dim myDateAdapter As New SqlDataAdapter(mySqlCommand) 
Dim ds As New DataSet 
myDateAdapter.Fill(ds, "dtName") 

Trudno wiedzieć, jakiego rodzaju błędy przejściowe wystąpią w środowisku produkcyjnym z Azure więc staram się robić jak najwięcej jak to możliwe złagodzenie teraz.

Answer 1

Sądzę, że ponowne próby będą częścią ogólnej operacji bazy danych SQL Azure w systemie Windows Azure.

Zamiast implementować niestandardowe rozwiązanie, czy przyjrzeć się transient fault handling application block opublikowanemu przez Microsoft Patterns and Practices, specjalnie dla bazy danych SQL?

Answer 2

Niepowodzenia połączenia w SQL Azure są częste. Dzieje się tak, ponieważ twoja aplikacja utworzy pulę połączeń, ale gdy twoja strona uzna, że ​​te połączenia już minęły, Azure może je zakończyć na końcu i nigdy się o tym nie dowiesz.

Robią to z ważnych powodów, takich jak konkretna instancja została przeciążona i przenoszą połączenia do innej. Z wewnętrznymi serwerami SQL zazwyczaj nie ma problemu, ponieważ serwery SQL są zawsze dostępne i dedykowane do użytku.

Jako przykład, otrzymuję około 5 awarii połączenia z SQL Azure na około 100 000 zapytań do bazy danych w ciągu jednego dnia.

To się stanie z SQL Azure. Jeśli korzystasz z ADO.NET, to sugestia Davida o przejściowej obsłudze błędów jest drogą do zrobienia.

Jeśli masz zamiar używać Entity Framework, nie jest dobre i złe wieści: Transient Fault Handling with SQL Azure using Entity Framework

Answer 3

I wprowadziły SqlConnection i SqlCommand metody rozszerzenie zapewniając ponowić logiki. Jest dostępny pod numerem NuGet.