Resilienza delle connessioni (JDBC)

Scaricare il driver JDBC

La resilienza della connessione consente al driver JDBC di ripristinare in modo trasparente una connessione inattiva e ripetere la connessione iniziale in caso di errore. Questo articolo illustra le due proprietà della stringa di connessione che controllano questo comportamento (connectRetryCount e connectRetryInterval) e le impostazioni keepalive usate dal driver per rilevare una connessione inattiva eliminata. La resilienza della connessione è disponibile a partire da Microsoft driver JDBC 10.2.0 per SQL Server. La riconnessione di una connessione inattiva richiede SQL Server 2014 o versione successiva o database SQL di Azure.

Tip

La resilienza della connessione ritenta solo la connessione iniziale e ripristina automaticamente le connessioni inattive. Per ripetere automaticamente le istruzioni non riuscite (ad esempio, deadlock victim 1205 o lock timeout 1222) o per estendere l'elenco di tentativi di connessione con numeri di errore personalizzati (ad esempio, Azure SQL errori temporanei, ad esempio 40197 o 40613), usare la logica di ripetizione dei tentativi configurabile. CRL è basato su regole, si selezionano gli errori e il backoff e funziona insieme alle funzionalità in questo articolo.

Come il driver JDBC esegue nuovi tentativi

Il driver JDBC fornisce tre meccanismi di ripetizione dei tentativi indipendenti. Interagiscono, in modo da poterli usare tutti contemporaneamente:

Meccanismo Funzionamento Dove saperne di più
Resilienza delle connessioni inattive Ripristina in modo trasparente una connessione inattiva interrotta, ad esempio una connessione in pool chiusa dal server o da un servizio di bilanciamento del carico. Rilevare le connessioni inattive (questo articolo)
Tentativo di connessione iniziale Riprova una connessione iniziale non riuscita a intervalli fissi per un elenco predefinito di errori transitori. Ripetere le connessioni iniziali (questo articolo)
Logica di ripetizione dei tentativi configurabile (CRL) Nuovo tentativo basato su regole per le istruzioni non riuscite e per i numeri di errore personalizzati. Introdotto in Microsoft JDBC Driver 12.10. Logica di ripetizione dei tentativi configurabile

Ripetere le connessioni iniziali

Il driver JDBC include due proprietà di connessione che controllano la frequenza e il tempo di attesa del driver prima di ritentare la connessione iniziale. Aggiungere queste proprietà al stringa di connessione o impostarle tramite le proprietà dell'origine dati.

Parola chiave Valori Valore predefinito Descrizione
connectRetryCount Numero intero compreso tra 0 e 255 inclusi 1 Il numero massimo di tentativi di stabilire o ristabilire una connessione prima di rinunciare. Per impostazione predefinita, il driver esegue un singolo tentativo. Il valore 0 disabilita la ripetizione dei tentativi.
connectRetryInterval Numero intero compreso tra 1 e 60 inclusi 10 L'intervallo di tempo, in secondi, tra i tentativi di riprovare una connessione. Il driver tenta di riconnettersi immediatamente quando rileva una connessione inattiva, quindi attende connectRetryInterval secondi prima di riprovare. Questa proprietà viene ignorata quando connectRetryCount è 0.

Se connectRetryCount * connectRetryInterval è maggiore di loginTimeout, il driver smette di tentare di connettersi una volta loginTimeout raggiunto. Altrimenti, continua finché connectRetryCount non si esaurisce.

Queste proprietà riprovano solo l'elenco predefinito di errori di connessione temporanei. Per l'elenco completo degli errori trattati (4060, 40197, 40501, 40613, 49918-49920 e altri), vedere Elenco di errori di connessione temporanei predefiniti. Per aggiungere numeri di errore personalizzati a questo set o sostituirli completamente, usare retryConn in Logica di ripetizione dei tentativi configurabile. Per ripetere le istruzioni non riuscite, usare retryExec nello stesso articolo.

Impostare le proprietà

Impostare connectRetryCount e connectRetryInterval nell'URL JDBC, in un Properties oggetto o in un oggetto SQLServerDataSource.

Nell'URL JDBC:

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

Con un oggetto Properties. I frammenti di codice Java in questo articolo omettono importazioni e wrapper di classe per brevità.

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

Con SQLServerDataSource:

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

Rilevare connessioni inattive interrotte

Una tipica connessione inattiva è quella presente in un pool di connessioni. Il driver considera inattiva una connessione dopo circa 30 secondi senza attività. Il server o un dispositivo di rete tra il client e il server possono chiudere le connessioni inattive, quindi il driver deve avere un modo per notare che il socket è inattivo prima dell'esecuzione della query successiva.

Per rilevare le connessioni inattive interrotte, il driver si affida ai pacchetti TCP keepalive a livello di socket. In Linux e Java 11 o versioni successive, il driver abilita automaticamente i pacchetti keepalive a un intervallo di 30 secondi (KeepAliveTime), con un ritardo di 1 secondo tra i tentativi quando si verifica un errore (KeepAliveInterval).

Importante

In Windows e in Java 11 o versioni precedenti, è necessario configurare i keepalives manualmente nel sistema operativo per sfruttare i vantaggi del ripristino della connessione inattiva interrotta. Per informazioni su come configurare i pacchetti keep-alive, vedere Connessione al database SQL di Azure.

Limiti

Il driver non può ripristinare una connessione inattiva interrotta quando si verifica una delle condizioni seguenti:

  • Esiste un set di risultati aperto che non è completamente analizzato o memorizzato nel buffer.
  • Database con cambio di connessione rispetto a Azure SQL.
  • C'è una transazione aperta.