Odporność połączenia (JDBC)

pobierz sterownik JDBC

Odporność połączenia umożliwia sterownikowi JDBC przezroczyste przywrócenie uszkodzonego bezczynnego połączenia i ponów próbę nawiązania połączenia początkowego, jeśli ulegnie awarii. W tym artykule omówiono dwie właściwości ciągu połączenia, które sterują tym zachowaniem (connectRetryCount i connectRetryInterval), oraz ustawienia keepalive używane przez sterownik do wykrywania zerwanego bezczynnego połączenia. Odporność połączeń jest dostępna od wersji 10.2.0 sterownika Microsoft JDBC Driver for SQL Server. Ponowne nawiązanie zerwanego nieaktywnego połączenia wymaga programu SQL Server 2014 lub nowszego albo usługi Azure SQL Database.

Jak sterownik JDBC ponawia próbę

Sterownik JDBC zapewnia trzy niezależne mechanizmy ponawiania prób. Współpracują ze sobą, aby można było używać wszystkich z nich jednocześnie:

Ponów próbę nawiązania połączeń początkowych

Sterownik JDBC zawiera dwie właściwości połączenia, które kontrolują, jak często i jak długo sterownik czeka przed ponowieniu próby nawiązania połączenia początkowego. Dodaj te właściwości do parametry połączenia lub ustaw je za pomocą właściwości źródła danych.

Sterownik natychmiast wykonuje pierwszą ponowną próbę i czeka connectRetryInterval sekund przed każdą następną, więc connectRetryCount ponowne próby zajmują łącznie około (connectRetryCount - 1) * connectRetryInterval sekund. loginTimeout wyznacza granicę dla całej sekwencji: sterownik przestaje ponawiać próby, gdy czas, który upłynął, plus connectRetryInterval osiąga loginTimeout, co następuje o jeden interwał przed samym loginTimeout.

Te właściwości powodują ponawianie prób tylko w przypadku wbudowanej listy przejściowych błędów połączenia. Pełną listę uwzględnionych błędów (4060, 40197, 40501, 40613, 49918–49920 i innych) można znaleźć w dokumencie Lista wbudowanych błędów przejściowych połączenia. Aby dodać niestandardowe numery błędów do tego zestawu lub zastąpić go w całości, użyj retryConn w Konfigurowanie logiki ponawiania prób. Aby ponowić nieudane instrukcje, użyj retryExec w tym samym artykule.

Ustawianie właściwości

Ustaw connectRetryCount i connectRetryInterval w adresie URL JDBC, w obiekcie Properties lub w obiekcie SQLServerDataSource.

W adresie URL JDBC:

jdbc:sqlserver://server;databaseName=db;connectRetryCount=3;connectRetryInterval=10

Za pomocą obiektu Properties. Fragmenty kodu Java w tym artykule pomijają importy i otoki klas w celu zwięzłości.

Properties props = new Properties();
props.setProperty("user", "...");
props.setProperty("password", "...");
props.setProperty("connectRetryCount", "3");
props.setProperty("connectRetryInterval", "10");
Connection c = DriverManager.getConnection("jdbc:sqlserver://server;databaseName=db", props);

Z użyciem SQLServerDataSource:

SQLServerDataSource ds = new SQLServerDataSource();
ds.setServerName("server");
ds.setDatabaseName("db");
ds.setUser("...");
ds.setPassword("...");
ds.setConnectRetryCount(3);
ds.setConnectRetryInterval(10);

Połącz się z automatycznie wstrzymaną bezserwerową bazą danych

Gdy używasz Azure SQL Database bez serwera z włączoną automatyczną pauzą, baza danych wznawia się przy pierwszej próbie połączenia. Ta próba kończy się niepowodzeniem z powodu błędu 40613 podczas działania operacji wznawiania. Bazy danych zazwyczaj wracają w mniej niż minutę. Więcej informacji znajdziesz w sekcji Automatyczne wstrzymywanie i automatyczne wznawianie.

Błąd 40613 znajduje się na wbudowanej liście błędów połączenia przejściowego, więc sterownik ponownie próbuje połączenie. Twoja aplikacja nie potrzebuje własnej pętli powtórek w tym przypadku. Domyślne ustawienia nie obejmują wznowienia: connectRetryCount to 1, a sterownik natychmiast wykonuje tę jedyną ponowną próbę. Obie próby następują podczas wznawiania się bazy danych, więc aplikacja zauważa błąd.

Aby obsłużyć CV, połącz wszystkie trzy cechy razem:

Następujące wartości powtarzają się przez około minutę, co obejmuje typowe CV:

jdbc:sqlserver://<server>.database.windows.net;databaseName=<database>;encrypt=true;loginTimeout=120;connectRetryCount=5;connectRetryInterval=15

Samo zwiększenie wartości loginTimeout nie pomaga, ponieważ próba połączenia szybko kończy się błędem 40613, zamiast zawisać. Samo podnoszenie connectRetryCount nie pomaga, bo loginTimeout skróca sekwencję.

Wykrywanie uszkodzonych bezczynnych połączeń

Typowe bezczynne połączenie to połączenie znajdujące się w puli połączeń. Sterownik uznaje połączenie za nieaktywne po około 30 sekundach bez aktywności. Serwer lub urządzenie sieciowe między klientem a serwerem może zamknąć bezczynne połączenia, dlatego sterownik potrzebuje sposobu, aby zauważyć, że gniazdo nie działa przed następnym uruchomieniem zapytania.

Aby wykryć uszkodzone bezczynne połączenia, sterownik opiera się na pakietach keepalive TCP na poziomie gniazda. Na Linuksie z wersjami Java 11 i nowszymi, sterownik automatycznie umożliwia pakiety keepalive w odstępie 30 sekund (KeepAliveTime), z 1-sekundowym opóźnieniem między ponownymi próbami w przypadku awarii (KeepAliveInterval).

Ograniczenia

Sterownik nie może przywrócić uszkodzonego bezczynnego połączenia, jeśli spełniony jest dowolny z następujących warunków:

• Istnieje otwarty zestaw wyników, który nie jest całkowicie analizowany ani buforowany.
• Połączenie przełączyło bazy danych na Azure SQL.
• Istnieje otwarta transakcja.

Treści powiązane

• Konfigurowalna logika ponawiania prób (JDBC)
• Nawiązywanie połączenia z bazą danych Azure SQL
• Opis właściwości limitu czasu w sterowniku JDBC
• Artykuł techniczny: Odporność bezczynnego połączenia
• Omówienie sterownika JDBC