Verbindungsstabilität (JDBC)

JDBC-Treiber herunterladen

Die Verbindungsresilienz ermöglicht es dem TREIBER, eine fehlerhafte Leerlaufverbindung transparent wiederherzustellen und die erste Verbindung erneut zu versuchen, wenn die Verbindung fehlschlägt. In diesem Artikel werden die beiden Verbindungszeichenfolgeneigenschaften behandelt, die dieses Verhalten steuern (connectRetryCount und connectRetryInterval) und die Keepalive-Einstellungen, die der Treiber verwendet, um eine verworfene Leerlaufverbindung zu erkennen. Die Verbindungsresilienz ist ab Microsoft JDBC-Treiber 10.2.0 für SQL Server verfügbar. Das Wiederherstellen einer unterbrochenen Idle-Verbindung erfordert SQL Server 2014 und spätere Versionen oder Azure SQL-Datenbank.

Wie der JDBC-Treiber Wiederholungsversuche durchführt

Der JDBC-Treiber bietet drei unabhängige Wiederholungsmechanismen. Sie arbeiten zusammen, damit Sie alle gleichzeitig verwenden können:

Wiederholen der ersten Verbindungen

Der JDBC-Treiber enthält zwei Verbindungseigenschaften, die steuern, wie oft und wie lange der Treiber wartet, bevor er erneut versucht, die ursprüngliche Verbindung herzustellen. Fügen Sie diese Eigenschaften dem Verbindungszeichenfolge hinzu, oder legen Sie sie über Datenquelleneigenschaften fest.

Der Fahrer führt den ersten Versuch sofort durch und wartet connectRetryInterval Sekunden vor jedem späteren, sodass connectRetryCount die erneuten Versuche etwa Sekunden (connectRetryCount - 1) * connectRetryInterval dauern. loginTimeout begrenzt die gesamte Sequenz: Der Treiber stellt die weiteren Wiederholungsversuche ein, sobald die verstrichene Zeit plus connectRetryIntervalloginTimeout erreicht, was ein Intervall vor loginTimeout selbst geschieht.

Diese Eigenschaften wiederholen nur die integrierte Liste der vorübergehenden Verbindungsfehler. Die vollständige Liste der behandelten Fehler (4060, 40197, 40501, 40613, 49918-49920 und andere) finden Sie in der Liste der integrierten vorübergehenden Verbindungsfehlerliste. Wenn Sie dieser Menge benutzerdefinierte Fehlernummern hinzufügen oder sie vollständig ersetzen möchten, verwenden Sie retryConn in Konfigurierbare Wiederholungslogik. Verwenden Sie retryExec zum Wiederholen fehlgeschlagener Anweisungen im selben Artikel.

Festlegen der Eigenschaften

Legen Sie connectRetryCount und connectRetryInterval in der JDBC-URL, in einem Properties-Objekt oder in einem SQLServerDataSource fest.

In der JDBC-URL:

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

Mit einem Properties-Objekt. Die Java Codeausschnitte in diesem Artikel lassen Importe und Klassenwrapper aus Platzgründen weg.

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);

Mit SQLServerDataSource:

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

Verbinden Sie sich mit einer automatisch pausierten serverlosen Datenbank

Wenn du Azure SQL-Datenbank serverlos mit aktivierter automatischer Pause verwendest, wird die Datenbank beim ersten Verbindungsversuch fortgesetzt. Dieser Versuch scheitert mit Fehler 40613, während der Resume läuft. Datenbanken werden in der Regel in weniger als einer Minute wieder aufgenommen. Weitere Informationen finden Sie unter Auto-pause und Auto-resume.

Fehler 40613 befindet sich in der eingebauten Liste der transienten Verbindungsfehler, daher versucht der Treiber die Verbindung erneut. Deine Anwendung benötigt in diesem Fall keine eigene Retry-Schleife. Die Standardeinstellungen decken kein Fortsetzen ab: connectRetryCount ist 1, und der Treiber führt diesen einzelnen Versuch sofort durch. Beide Versuche erfolgen, während die Datenbank noch wieder hochfährt, sodass die Anwendung eine Fehlermeldung erhält.

Um einen Lebenslauf zu bearbeiten, setzen Sie alle drei Eigenschaften zusammen:

Die folgenden Werte werden etwa eine Minute lang immer wieder wiederholt, was ein typisches Fortsetzen abdeckt:

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

Das Hochskalieren von loginTimeout allein hilft nicht, da der Verbindungsversuch mit 40613 schnell fehlschlägt, anstatt zu hängen. Das alleinige Erhöhen von connectRetryCount hilft ebenfalls nicht, weil loginTimeout die Sequenz verkürzt.

Erkennen fehlerhafter Leerlaufverbindungen

Eine typische im Leerlauf befindliche Verbindung ist eine, die sich in einem Verbindungspool befindet. Der Treiber betrachtet eine Verbindung nach etwa 30 Sekunden ohne Aktivität als inaktiv. Der Server oder ein Netzwerkgerät zwischen dem Client und dem Server kann Leerlaufverbindungen schließen, sodass der Treiber eine Möglichkeit benötigt, um zu erkennen, dass der Socket tot ist, bevor die nächste Abfrage ausgeführt wird.

Um unterbrochene Leerlaufverbindungen zu ermitteln, verwendet der Treiber TCP-Keepalive-Pakete auf Socketebene. Unter Linux mit Java 11 und neueren Versionen aktiviert der Treiber automatisch Keepalive-Pakete im 30-Sekunden-Intervall (KeepAliveTime), mit einer Verzögerung von 1 Sekunde zwischen den erneuten Versuchen, wenn ein Fehler auftritt (KeepAliveInterval).

Einschränkungen

Der Treiber kann eine fehlerhafte Leerlaufverbindung nicht wiederherstellen, wenn eine der folgenden Bedingungen zutrifft:

• Es ist eine offene Ergebnismenge vorhanden, die nicht vollständig geparst oder gepuffert ist.
• Die Verbindung hat Datenbanken für Azure SQL gewechselt.
• Es gibt eine geöffnete Transaktion.

Verwandte Inhalte

• Konfigurierbare Wiederholungslogik (JDBC)
• Herstellen einer Verbindung mit einer Azure SQL-Datenbank
• Grundlagen zu Timeout-Eigenschaften im JDBC-Treiber
• Technischer Artikel: Ausfallsicherheit der Leerlaufverbindung
• Übersicht über den JDBC-Treiber