Resposta curta:nenhum (por padrão).
Para constar (para incluir detalhes aqui caso o link mude), estamos falando da propriedade
maxLifetime de HikariCP:
Essa propriedade controla o tempo de vida máximo de uma conexão no pool. Uma conexão em uso nunca será desativada, somente quando for fechada ela será removida. Recomendamos definir esse valor, que deve ser pelo menos 30 segundos a menos do que qualquer limite de tempo de conexão imposto por banco de dados ou infraestrutura. Um valor de 0 indica que não há tempo de vida máximo (tempo de vida infinito), sujeito, é claro, à configuração de idleTimeout. Padrão:1800000 (30 minutos)
Na minha experiência, é bom que o HikariCP faça isso. Até onde eu sei, por padrão, a Oracle não impõe um tempo de vida máximo para conexões (nem no lado do driver JDBC (1), nem no lado do servidor (2)). Portanto, a esse respeito, o "limite de tempo de conexão imposto pela infraestrutura " é +infinito -- e isso foi um problema para nós, pois observamos problemas com conexões de longa duração. Isso também significa que qualquer valor é "pelo menos 30 segundos a menos ", incluindo o padrão :)
Eu suponho a camada de conexão não faz nada sobre isso porque conta com a camada de pool acima para lidar com essas coisas. Não era possível com o pool de conexões implícitas (agora obsoleto), e não sei se o UCP (o substituto) faz isso, mas se você usar o HikariCP, não os usará.
Agora, após 30 minutos (geralmente após muitas reutilizações para vários fins) para uma determinada conexão, o HikariCP a fecha e cria uma nova. Isso tem um custo muito pequeno e corrigiu nossos problemas com conexões de longa duração. Estamos felizes com esse padrão, mas ainda o tornamos configurável por precaução (veja 2 abaixo).
(1)
OracleDataSource não oferece nenhum ponto de configuração (propriedade ou propriedade do sistema) para controlar isso, e eu observei vida infinita. (2) Para limites do lado do servidor, consulte o parâmetro de perfil
IDLE_TIME . Citando esta resposta:
O Oracle por padrão não fechará uma conexão devido à inatividade. Você pode configurar um perfil com um IDLE_TIME para fazer com que o Oracle feche conexões inativas.
Para verificar qual é o valor de
IDLE_TIME para seu usuário, combinando as respostas deste Q&A:select p.limit
from dba_profiles p, dba_users u
where p.resource_name = 'IDLE_TIME' and p.profile = u.profile and u.username = '...'
;
O valor padrão é
UNLIMITED . Observe que pode haver outros limites impostos em outros lugares (firewall... ) que podem interferir. Então é melhor torná-lo configurável , caso esses problemas sejam descobertos ao implantar seu produto.
No Linux, você pode verificar a duração máxima das conexões físicas monitorando os soquetes TCP conectados ao seu banco de dados. Estou executando o script abaixo no meu servidor (do ponto de vista do banco de dados, esse é o cliente host), leva 1 argumento, o
ip:port do seu nó oracle, como aparece na saída de netstat -tan (ou um padrão se você tiver vários nós). #!/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"
Se você executar isso e parar com ctrl-c durante
sleep tempo, ele deve sair do loop e limpar o diretório temporário, mas isso não é 100% infalível Nos resultados nenhuma das portas deve mostrar um valor que exceda 1800 segundos (ou seja, 30 minutos), mais ou menos um minuto. Veja a saída de exemplo abaixo, a primeira amostra mostra 2 soquetes acima de 1800s, eles desaparecem 10s depois.
------------ 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
Você precisará executar o script por mais de 30 minutos para ver isso, porque ele não sabe a idade dos soquetes que existiam antes
