Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La resistencia de conexión permite que el controlador JDBC restaure de forma transparente una conexión inactiva interrumpida y vuelva a intentar la conexión inicial si se produce un error. En este artículo se explican las dos propiedades de la cadena de conexión que controlan este comportamiento (connectRetryCount y connectRetryInterval) y la configuración de keepalive que usa el controlador para detectar una conexión inactiva interrumpida. La resistencia a errores de conexión está disponible a partir de la versión 10.2.0 del controlador JDBC de Microsoft para SQL Server. La reconexión de una conexión inactiva interrumpida requiere SQL Server 2014 o posterior, o Azure SQL Database.
Tip
La resistencia de la conexión solo reintenta la conexión inicial y restaura silenciosamente las conexiones inactivas interrumpidas. Para reintentar automáticamente las instrucciones que han fallado (por ejemplo, el error 1205 de víctima de interbloqueo o el error 1222 de tiempo de espera de bloqueo), o para ampliar la lista de reintentos de conexión con números de error personalizados (por ejemplo, errores transitorios de Azure SQL como 40197 o 40613), use la lógica de reintento configurable. CRL se basa en reglas: tú eliges los errores y el retroceso, y funciona junto con las funciones descritas en este artículo.
Cómo realiza reintentos el controlador JDBC
El controlador JDBC proporciona tres mecanismos de reintento independientes. Trabajan juntos, por lo que puede usar todos ellos a la vez:
| Mecanismo | Qué hace | Dónde obtener más información |
|---|---|---|
| Resistencia de conexión inactiva | Restaura de forma transparente una conexión inactiva interrumpida (por ejemplo, una conexión agrupada cerrada por el servidor o un equilibrador de carga). | Detectar conexiones inactivas interrumpidas (este artículo) |
| Reintento de conexión inicial | Reintenta una conexión inicial fallida según una programación fija para una lista predefinida de errores transitorios. | Reintentar las conexiones iniciales (este artículo) |
| Lógica de reintento configurable (CRL) | Reintento basado en reglas para instrucciones fallidas y números de error personalizados. Se introdujo en Microsoft JDBC Driver 12.10. | Lógica de reintento configurable |
Reintentar conexiones iniciales
El controlador JDBC incluye dos propiedades de conexión que controlan con qué frecuencia y cuánto tiempo espera el controlador antes de reintentar la conexión inicial. Agregue estas propiedades al cadena de conexión o establézcalas a través de las propiedades del origen de datos.
| Palabra clave | Valores | Valor predeterminado | Descripción |
|---|---|---|---|
connectRetryCount |
Un entero comprendido entre 0 y 255, ambos incluidos | 1 | El número máximo de intentos de establecer o restablecer una conexión antes de abandonar. De forma predeterminada, el controlador realiza un único reintento. Valor de 0 deshabilita el reintento. |
connectRetryInterval |
Un entero comprendido entre 1 y 60, ambos incluidos | 10 | Tiempo en segundos entre los reintentos de conexión. El controlador intenta volver a conectarse inmediatamente cuando detecta una conexión inactiva interrumpida y, a continuación, espera connectRetryInterval segundos antes de intentarlo de nuevo. Esta propiedad se omite cuando connectRetryCount es 0. |
Si connectRetryCount * connectRetryInterval es mayor que loginTimeout, el controlador deja de intentar conectarse una vez loginTimeout alcanzado. De lo contrario, continúa hasta que connectRetryCount se agote.
Estas propiedades reintentan solo la lista integrada de errores de conexión transitorios. Para obtener la lista completa de errores cubiertos (4060, 40197, 40501, 40613, 49918-49920, etc.), consulte Lista de errores de conexión transitorios integrados. Para agregar números de error personalizados a este conjunto o reemplazarlos por completo, use retryConn en lógica de reintento configurable. Para reintentar instrucciones fallidas, utilice retryExec en el mismo artículo.
Establezca las propiedades
Establezca connectRetryCount y connectRetryInterval en la URL de JDBC, en un objeto Properties o en un SQLServerDataSource.
En la dirección URL de JDBC:
jdbc:sqlserver://server;databaseName=db;connectRetryCount=3;connectRetryInterval=10
Con un objeto Properties. Los fragmentos de código de Java de este artículo omiten las importaciones y los contenedores de clases para mayor brevedad.
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);
Detección de conexiones inactivas interrumpidas
Una conexión inactiva típica es la que permanece en un pool de conexiones. El controlador considera que una conexión está inactiva después de unos 30 segundos sin actividad. El servidor o un dispositivo de red entre el cliente y el servidor pueden cerrar las conexiones inactivas, por lo que el controlador necesita una manera de observar que el socket está inactivo antes de que se ejecute la siguiente consulta.
Para detectar conexiones inactivas interrumpidas, el controlador se basa en paquetes keepalive TCP en el nivel de socket. En Linux y Java 11 o posterior, el controlador habilita automáticamente paquetes keepalive a un intervalo de 30 segundos (KeepAliveTime), con un retraso de 1 segundo entre reintentos cuando se produce un error (KeepAliveInterval).
Importante
En Windows y en Java 11 o versiones anteriores, debe configurar manualmente los keepalives en el sistema operativo para aprovechar la recuperación de conexiones inactivas interrumpidas. Para obtener información sobre cómo configurar keepalives, consulte Conexión a base de datos de Azure SQL.
Limitaciones
El controlador no puede restaurar una conexión inactiva interrumpida cuando se cumple alguna de las condiciones siguientes:
- Hay un conjunto de resultados abierto que no se ha analizado ni almacenado en búfer por completo.
- La conexión cambió de base de datos en Azure SQL.
- Hay una transacción abierta.