Respuesta corta:ninguno (por defecto).
Para que conste (para incluir detalles aquí en caso de que cambie el enlace), estamos hablando de la propiedad maxLifetime de HikariCP:
Esta propiedad controla la duración máxima de una conexión en el grupo. Una conexión en uso nunca se retirará, solo se eliminará cuando se cierre. Recomendamos enfáticamente establecer este valor, y debe ser al menos 30 segundos menos que el límite de tiempo de conexión impuesto por cualquier base de datos o infraestructura. Un valor de 0 indica que no hay tiempo de vida máximo (tiempo de vida infinito), sujeto, por supuesto, a la configuración de idleTimeout. Predeterminado:1800000 (30 minutos)
En mi experiencia, es bueno que HikariCP haga eso. Por lo que sé, de forma predeterminada, Oracle no aplica una vida útil máxima para las conexiones (ni en el lado del controlador JDBC (1), ni en el lado del servidor (2)). En este sentido, el "límite de tiempo de conexión impuesto por la infraestructura " es +infinito, y eso fue un problema para nosotros, ya que observamos problemas con conexiones de larga duración. También significa que cualquier valor es "al menos 30 segundos menos ", incluido el predeterminado :)
Yo supongo la capa de conexión no hace nada al respecto porque cuenta con la capa de grupo de arriba para manejar tales cosas. No era posible con el grupo de conexiones implícitas (ahora en desuso), y no sé si UCP (el reemplazo) hace eso, pero si usa HikariCP, no los usa.
Ahora, después de 30 minutos (generalmente después de muchas reutilizaciones para varios propósitos) para una conexión determinada, HikariCP la cierra y crea una nueva. Eso tiene un costo muy pequeño y solucionó nuestros problemas con conexiones de larga duración. Estamos contentos con ese valor predeterminado, pero aun así lo hacemos configurable por si acaso (ver 2 a continuación).
(1) OracleDataSource no ofrece ningún punto de configuración (propiedad o propiedad del sistema) para controlar eso, y observé vida infinita.
(2) Para conocer los límites del lado del servidor, consulte el parámetro de perfil IDLE_TIME . Citando esta respuesta:
Oracle por defecto no cerrará una conexión debido a la inactividad. Puede configurar un perfil con IDLE_TIME para que Oracle cierre las conexiones inactivas.
Para verificar cuál es el valor de IDLE_TIME para su usuario, combinando las respuestas de estas preguntas y respuestas:
select p.limit
from dba_profiles p, dba_users u
where p.resource_name = 'IDLE_TIME' and p.profile = u.profile and u.username = '...'
;
El valor predeterminado es UNLIMITED .
Tenga en cuenta que puede haber otros límites aplicados en otros lugares (cortafuegos...) que podrían interferir. Así que será mejor que lo hagas configurable , en caso de que se descubran dichos problemas cuando implemente su producto.
En Linux, puede verificar la vida útil máxima de las conexiones físicas al monitorear los sockets TCP conectados a su base de datos. He estado ejecutando el siguiente script en mi servidor (desde el punto de vista de la base de datos, ese es el cliente host), toma 1 argumento, el ip:port de su nodo Oracle, tal como aparece en la salida de netstat -tan (o un patrón si tiene varios nodos).
#!/bin/bash
target="$1"
dir=$(mktemp -d)
while sleep 10
do
echo "------------ "$(date)
now=$(date +%s)
netstat -tan | grep " $target " | awk '{print $4}' | cut -f2 -d: | while read port
do
file="p_$port"
[ ! -e $file ] && touch $file
ftime=$(stat -c %Z "$file")
echo -e "$port :\t "$(( now - ftime))
done
done
\rm "$dir"/p_*
\rmdir "$dir"
Si ejecuta eso y lo detiene con ctrl-c durante sleep tiempo, debería salir del ciclo y limpiar el directorio temporal, pero esto no es 100% infalible
En los resultados ninguno de los puertos debe mostrar un valor que supere los 1800 segundos (es decir, 30 minutos), más o menos un minuto. Vea el resultado de ejemplo a continuación, la primera muestra muestra 2 enchufes por encima de 1800, se han ido 10 segundos después.
------------ Thu Jul 6 16:09:00 CEST 2017
49806 : 1197
49701 : 1569
49772 : 1348
49782 : 1317
49897 : 835
49731 : 1448
49620 : 1830
49700 : 1569
49986 : 523
49722 : 1498
49715 : 1509
49711 : 1539
49629 : 1820
49732 : 1448
50026 : 332
49849 : 1036
49858 : 1016
------------ Thu Jul 6 16:09:10 CEST 2017
49806 : 1207
49701 : 1579
49772 : 1358
49782 : 1327
49897 : 845
49731 : 1458
49700 : 1579
49986 : 533
49722 : 1508
49715 : 1519
49711 : 1549
49732 : 1458
50026 : 342
49849 : 1046
49858 : 1026
Tendrá que ejecutar el script durante más de 30 minutos para ver eso, porque no sabe la antigüedad de los sockets que existían antes
