Résilience de connexion (JDBC)

Télécharger le pilote JDBC

La résilience de connexion permet au pilote JDBC de restaurer de manière transparente une connexion inactive rompue et de réessayer la connexion initiale en cas d’échec. Cet article décrit les deux propriétés de chaîne de connexion qui contrôlent ce comportement (connectRetryCount et connectRetryInterval) et les paramètres keepalive que le pilote utilise pour détecter une connexion inactive supprimée. La résilience de connexion est disponible à partir de Microsoft JDBC Driver 10.2.0 pour SQL Server. Reconnecter une connexion inactive défaillante nécessite SQL Server 2014 et versions ultérieures, ou Azure SQL Database.

Tip

La résilience de connexion retente uniquement la connexion initiale et restaure silencieusement les connexions inactives rompues. Pour réessayer automatiquement les instructions ayant échoué (par exemple, victime d’interblocage 1205 ou délai d’expiration du verrouillage 1222), ou pour étendre la liste des tentatives de reconnexion avec des numéros d’erreur personnalisés (par exemple, les erreurs temporaires Azure SQL telles que 40197 ou 40613), utilisez la logique de nouvelle tentative configurable. CRL est basé sur des règles ; vous définissez les erreurs et la stratégie de repli, et il fonctionne avec les fonctionnalités décrites dans cet article.

Comment le pilote JDBC effectue de nouvelles tentatives

Le pilote JDBC fournit trois mécanismes de nouvelle tentative indépendants. Ils travaillent ensemble, de sorte que vous pouvez les utiliser à la fois :

Mécanisme Qu’est-ce que cela fait ? Où en savoir plus
Résilience des connexions inactives Restaure en toute transparence une connexion inactive interrompue (par exemple, une connexion mise en pool fermée par le serveur ou un équilibreur de charge). Détecter les connexions inactives rompues (cet article)
Nouvelle tentative de connexion initiale Relance la connexion initiale ayant échoué à intervalles fixes pour une liste intégrée d’erreurs transitoires. Réessayer les connexions initiales (cet article)
Logique de nouvelle tentative configurable (CRL) Nouvelle tentative basée sur des règles pour les instructions ayant échoué et pour les numéros d’erreur personnalisés. Introduit dans Microsoft JDBC Driver 12.10. Logique de nouvelle tentative configurable

Réessayer les connexions initiales

Le pilote JDBC inclut deux propriétés de connexion qui contrôlent la fréquence et la durée pendant laquelle le pilote attend avant de réessayer la connexion initiale. Ajoutez ces propriétés au chaîne de connexion ou définissez-les via des propriétés de source de données.

Mot clé Valeurs Par défaut Description
connectRetryCount Entier compris entre 0 et 255 (inclus) 1 Nombre maximal de tentatives pour établir ou rétablir une connexion avant abandon. Par défaut, le pilote effectue une nouvelle tentative unique. Une valeur de 0 désactive les nouvelles tentatives.
connectRetryInterval Entier compris entre 1 et 60 (inclus) 10 Durée en secondes entre chaque nouvelle tentative de connexion. Le pilote tente de se reconnecter immédiatement lorsqu’il détecte une connexion inactive interrompue, puis attend quelques secondes connectRetryInterval avant de réessayer. Cette propriété est ignorée lorsque connectRetryCount c’est 0.

Le pilote lance immédiatement la première tentative et attend connectRetryInterval quelques secondes avant de chaque suivante, donc connectRetryCount les tentatives s’étendent sur environ (connectRetryCount - 1) * connectRetryInterval quelques secondes. loginTimeout limite toute la séquence : le conducteur cesse de réessayer une fois que le temps écoulé plus connectRetryInterval atteint loginTimeout, ce qui se produit un intervalle avant loginTimeout lui-même.

Ces propriétés réessayent uniquement la liste intégrée des erreurs de connexion temporaires. Pour obtenir la liste complète des erreurs couvertes (4060, 40197, 40501, 40613, 49918-49920, etc.), consultez la liste d’erreurs de connexion temporaire intégrée. Pour ajouter des numéros d’erreur personnalisés à cet ensemble, ou le remplacer entièrement, utilisez retryConn dans Logique de nouvelle tentative configurable. Pour réessayer les instructions ayant échoué, utilisez retryExec dans le même article.

Caution

Si vous définissez retryConn sans début +, cela remplace la liste intégrée au lieu de l’étendre. Toute erreur intégrée que vous ne mentionnez pas vous-même, y compris le 40613, n’est plus réessayée.

Définir les propriétés

Définissez connectRetryCount et connectRetryInterval dans l’URL JDBC, sur un Properties objet ou sur un SQLServerDataSource.

Dans l’URL JDBC :

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

Avec l’objet Properties. Les extraits de code Java de cet article omettent les importations et les wrappers de classe pour la concision.

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

Avec SQLServerDataSource :

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

Connectez-vous à une base de données serverless mise en pause automatiquement

Lorsque vous utilisez Azure SQL Database sans serveur avec l’auto-pause activée, la base de données reprend dès la première tentative de connexion. Cette tentative échoue avec l’erreur 40613 pendant l’exécution de l’opération de reprise. Les bases de données reprennent généralement en moins d’une minute. Pour plus d’informations, voir Mise en pause automatique et reprise automatique.

L’erreur 40613 figure dans la liste d’erreur intégrée des connexions transitoires, donc le pilote réessaie la connexion. Votre application n’a pas besoin de sa propre boucle de tentative pour ce cas. Les paramètres par défaut ne prennent pas en charge une reprise : connectRetryCount est 1, et le pilote exécute immédiatement cette unique nouvelle tentative. Les deux tentatives se produisent alors que la base de données est encore en train de reprendre, donc l’application détecte l’erreur.

Pour gérer un CV, mettez les trois propriétés ensemble :

Propriété Pourquoi cela se produit-il
connectRetryCount Définit le nombre de tentatives autorisées. Régle-le au-dessus du par défaut de 1.
connectRetryInterval Espace les nouvelles tentatives. La première tentative est immédiate ; le pilote attend ce délai avant chacune des tentatives suivantes.
loginTimeout Délimite la séquence entière. Le conducteur cesse de réessayer une fois que le temps écoulé plus connectRetryInterval atteint loginTimeout.

Les valeurs suivantes sont réessayées pendant environ une minute, ce qui couvre un CV typique :

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

Augmenter loginTimeout à lui seul n’aide pas, car la tentative de connexion échoue rapidement en renvoyant l’erreur 40613 au lieu de rester bloquée. Augmenter connectRetryCount à lui seul n’aide pas non plus, car loginTimeout interrompt prématurément la séquence.

Détecter les connexions inactives rompues

Une connexion inactive typique est une connexion qui se trouve dans un pool de connexions. Le pilote considère qu’une connexion est inactive après environ 30 secondes sans activité. Le serveur ou un périphérique réseau entre le client et le serveur peut fermer les connexions inactives. Le pilote a donc besoin d’un moyen de remarquer que le socket est mort avant l’exécution de la requête suivante.

Pour détecter les connexions inactives rompues, le pilote s’appuie sur des paquets keepalive TCP au niveau des sockets. Sous Linux avec Java 11 et versions ultérieures, le pilote active automatiquement les paquets keepalive à un intervalle de 30 secondes (KeepAliveTime), avec un délai d’une seconde entre les tentatives en cas d’échec (KeepAliveInterval).

Important

Sous Windows et avec Java 11 ou version antérieure, vous devez configurer manuellement les mécanismes de maintien de connexion dans le système d’exploitation pour tirer parti de la récupération des connexions inactives interrompues. Pour plus d’informations sur la configuration des keepalives, consultez Connexion à une base de données Azure SQL.

Limites

Le pilote ne peut pas restaurer une connexion inactive interrompue lorsque l’une des conditions suivantes est remplie :

  • Il existe un jeu de résultats ouvert qui n’est pas complètement analysé ou mis en mémoire tampon.
  • La connexion a changé de base de données par rapport à Azure SQL.
  • Il existe une transaction ouverte.

Contenu connexe

  • Last updated on