Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Med anslutningsåterhämtning kan JDBC-drivrutinen transparent återställa en bruten inaktiv anslutning och försöka den första anslutningen igen om den misslyckas. Den här artikeln beskriver de två egenskaperna för anslutningssträngar som styr det här beteendet (connectRetryCount och connectRetryInterval) och keepalive-inställningarna som drivrutinen använder för att identifiera en inaktiv anslutning som släppts. Motståndskraft mot anslutningsavbrott finns tillgängligt från och med Microsoft JDBC Driver 10.2.0 för SQL Server. Att återansluta en bruten inaktiv anslutning kräver SQL Server 2014 eller senare, eller Azure SQL Database.
Tip
Anslutningsåterhämtningen försöker bara återansluta den inledande anslutningen och återställer i tysthet brutna inaktiva anslutningar. Om du vill försöka med misslyckade instruktioner automatiskt (till exempel deadlock victim 1205 eller lock timeout 1222) eller för att utöka listan över anslutningsförsök med anpassade felnummer (till exempel Azure SQL tillfälliga fel som 40197 eller 40613) använder du Konfigurerbar omförsökslogik. CRL är regelbaserad, du väljer felen och reservlösningen, och den fungerar tillsammans med funktionerna som beskrivs i den här artikeln.
Så här gör JDBC-drivrutinen nya försök
JDBC-drivrutinen innehåller tre oberoende återförsöksmekanismer. De fungerar tillsammans, så att du kan använda dem alla samtidigt:
| Mekanism | Vad det gör | Var du kan lära dig mer |
|---|---|---|
| Återhämtning vid inaktiv anslutning | Återställer automatiskt en bruten vilande anslutning (till exempel en poolad anslutning som har stängts av servern eller en lastbalanserare). | Identifiera brutna inaktiva anslutningar (den här artikeln) |
| Första anslutningsförsöket | Försöker igen med en misslyckad inledande anslutning enligt ett fast schema för en inbyggd lista över tillfälliga fel. | Försök igen med inledande anslutningar (den här artikeln) |
| Konfigurerbar omprövningslogik (CRL) | Regelbaserat återförsök för misslyckade instruktioner och anpassade felnummer. Introducerades i Microsoft JDBC Driver 12.10. | Konfigurerbar omprövningslogik |
Försök ansluta igen
JDBC-drivrutinen innehåller två anslutningsegenskaper som styr hur ofta och hur länge drivrutinen väntar innan den första anslutningen försöker igen. Lägg till de här egenskaperna i reťazec pripojenia eller ange dem via datakällans egenskaper.
| Keyword | Värden | Förinställning | Description |
|---|---|---|---|
connectRetryCount |
Heltal mellan 0 och 255 (inklusive) | 1 | Det maximala antalet försök att upprätta eller återupprätta en anslutning innan du ger upp. Som standard gör drivrutinen ett nytt försök en gång. Värdet 0 inaktiverar återförsök. |
connectRetryInterval |
Heltal mellan 1 och 60 (inklusive) | 10 | Tiden, i sekunder, mellan återförsök av anslutningen. Drivrutinen försöker återansluta omedelbart när den upptäcker en bruten inaktiv anslutning och väntar sedan connectRetryInterval sekunder innan den försöker igen. Den här egenskapen ignoreras när connectRetryCount är 0. |
Om connectRetryCount * connectRetryInterval är större än loginTimeout slutar drivrutinen att försöka ansluta när loginTimeout har nåtts. Annars fortsätter den tills connectRetryCount har förbrukats.
Dessa egenskaper försöker bara igen den inbyggda listan över tillfälliga anslutningsfel. Den fullständiga listan över fel som omfattas (4060, 40197, 40501, 40613, 49918-49920 och andra) finns i Listan över inbyggda tillfälliga anslutningsfel. Om du vill lägga till anpassade felnummer i den här uppsättningen eller ersätta den helt använder du retryConn i Konfigurerbar omprövningslogik. Om du vill försöka igen med misslyckade satser använder du retryExec i samma artikel.
Ange egenskaperna
Ange connectRetryCount och connectRetryInterval i JDBC-URL:en, på ett Properties objekt eller på en SQLServerDataSource.
I JDBC-URL:en:
jdbc:sqlserver://server;databaseName=db;connectRetryCount=3;connectRetryInterval=10
Med ett Properties objekt. De Java kodfragmenten i den här artikeln utelämnar importer och klassomslutningar för korthet.
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);
Med SQLServerDataSource:
SQLServerDataSource ds = new SQLServerDataSource();
ds.setServerName("server");
ds.setDatabaseName("db");
ds.setUser("...");
ds.setPassword("...");
ds.setConnectRetryCount(3);
ds.setConnectRetryInterval(10);
Identifiera brutna inaktiva anslutningar
En typisk inaktiv anslutning är en som sitter i en anslutningspool. Drivrutinen anser att anslutningen är inaktiv efter cirka 30 sekunder utan aktivitet. Servern eller en nätverksenhet mellan klienten och servern kan stänga inaktiva anslutningar, så drivrutinen behöver ett sätt att märka att socketen är död innan nästa fråga körs.
För att identifiera brutna inaktiva anslutningar förlitar sig drivrutinen på TCP keepalive-paket på socketnivå. I Linux och Java 11 eller senare aktiverar drivrutinen automatiskt keepalive-paket med ett intervall på 30 sekunder (KeepAliveTime), med en fördröjning på 1 sekund mellan återförsök när ett fel inträffar (KeepAliveInterval).
Viktigt!
På Windows och på Java 11 eller tidigare måste du konfigurera keepalives manuellt i operativsystemet för att dra nytta av återställning av bruten inaktiv anslutning. Information om hur du konfigurerar keepalives finns i Anslutning till Azure SQL-databas.
Begränsningar
Drivrutinen kan inte återställa en bruten inaktiv anslutning när något av följande villkor gäller:
- Det finns en öppen resultatuppsättning som inte är helt parsad eller buffrad.
- Anslutningen bytte databaser mot Azure SQL.
- Det finns en öppen transaktion.