Anslutningsmotståndskraft (JDBC)

Ladda ned JDBC-drivrutin

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 trasig inaktivanslutning kräver SQL Server 2014 och senare versioner, 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.

Föraren gör det första försöket direkt och väntar connectRetryInterval sekunder innan varje senare, så connectRetryCount omförsök tar ungefär (connectRetryCount - 1) * connectRetryInterval några sekunder. loginTimeout avgränsar hela sekvensen: drivrutinen slutar göra nya försök när den förflutna tiden plus connectRetryInterval når loginTimeout, vilket sker ett intervall före själva loginTimeout.

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.

Caution

Om du sätter retryConn utan en inledning +, ersätter den den inbyggda listan istället för att utöka den. Alla inbyggda fel du inte anger själv, inklusive 40613, görs inte längre om.

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

Koppla upp dig mot en automatiskt pausad serverlös databas

När du använder Azure SQL Database serverless med auto-paus aktiverad, återupptas databasen vid första anslutningsförsöket. Detta försök misslyckas med felet 40613 när återupptagningen körs. Databaser återupptas vanligtvis på mindre än en minut. Mer information finns i Automatisk paus och automatisk återupptagning.

Fel 40613 finns i den inbyggda listan över tillfälliga anslutningsfel, så drivrutinen försöker återansluta. Din applikation behöver inte en egen omprövningsloop i det här fallet. Standardinställningarna omfattar inte återupptagning: connectRetryCount är 1, och drivrutinen utför det enda nya försöket omedelbart. Båda försöken sker medan databasen fortfarande återupptas, så applikationen ser felet.

För att hantera ett CV, sätt alla tre egenskaper tillsammans:

Property Varför det spelar roll
connectRetryCount Bestämmer hur många omförsök du får. Sätt den högre än standardvärdet för 1.
connectRetryInterval Sprider ut omförsöken. Det första försöket är omedelbart; föraren väntar så länge innan varje senare försök.
loginTimeout Avgränsar hela sekvensen. Föraren slutar försöka igen när den passerade tiden plus connectRetryInterval når loginTimeout.

Följande värden upprepas i ungefär en minut, vilket täcker ett typiskt CV:

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

Att höja loginTimeout i sig hjälper inte, eftersom anslutningsförsöket misslyckas snabbt med 40613 i stället för att fastna. Att höja connectRetryCount på egen hand hjälper inte heller, eftersom loginTimeout avbryter sekvensen i förtid.

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å. På Linux med Java 11 och senare versioner aktiverar drivrutinen automatiskt keepalive-paket med 30 sekunders intervall (KeepAliveTime), med en fördröjning på 1 sekund mellan fö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.

Relaterat innehåll

  • Last updated on