Krátká odpověď:žádná (ve výchozím nastavení).
Pro pořádek (abychom zde uvedli podrobnosti pro případ, že by se odkaz změnil), mluvíme o vlastnosti maxLifetime z HikariCP:
Tato vlastnost řídí maximální životnost připojení ve fondu. Používané připojení nebude nikdy zrušeno, pouze když bude uzavřeno, bude odstraněno. Důrazně doporučujeme nastavit tuto hodnotu a měla by být alespoň o 30 sekund kratší, než je časový limit připojení stanovený jakoukoli databází nebo infrastrukturou. Hodnota 0 znamená, že neexistuje maximální životnost (nekonečná životnost), samozřejmě v závislosti na nastavení idleTimeout. Výchozí:1800000 (30 minut)
Podle mých zkušeností je dobře, že to HikariCP dělá. Pokud mohu říci, ve výchozím nastavení Oracle nevynucuje maximální životnost připojení (ani na straně ovladače JDBC (1), ani na straně serveru (2)). Takže v tomto ohledu „infrastruktura-vynucený časový limit připojení “ je +nekonečno – a to byl pro nás problém, protože jsme zaznamenali problémy s dlouhotrvajícími připojeními. Znamená to také, že jakákoli hodnota je „nejméně o 30 sekund méně ", včetně výchozího :)
Předpokládám spojovací vrstva s tím nic nedělá, protože počítá s výše uvedenou vrstvou fondu, že takové věci zvládne. Nebylo to možné s (nyní zastaralým) implicitním fondem připojení a nevím, jestli to dělá UCP (náhrada), ale pokud používáte HikariCP, nepoužíváte je.
Nyní, po 30 minutách (obvykle po mnoha opakovaných použitích pro různé účely) pro dané připojení, jej HikariCP zavře a vytvoří nové. To má velmi nízké náklady a vyřešilo to naše problémy s dlouhodobými připojeními. S tímto výchozím nastavením jsme spokojeni, ale stále jej můžeme pro každý případ konfigurovat (viz 2 níže).
(1) OracleDataSource nenabízí žádný konfigurační bod (vlastnost nebo vlastnost systému), který by to ovládal, a zpozoroval jsem nekonečný život.
(2) Limity na straně serveru viz parametr profilu IDLE_TIME . Cituji tuto odpověď:
Oracle ve výchozím nastavení neuzavře připojení z důvodu nečinnosti. Můžete nakonfigurovat profil s IDLE_TIME, aby Oracle ukončil neaktivní připojení.
Chcete-li ověřit, jaká je hodnota IDLE_TIME pro vašeho uživatele kombinací odpovědí z těchto otázek a odpovědí:
select p.limit
from dba_profiles p, dba_users u
where p.resource_name = 'IDLE_TIME' and p.profile = u.profile and u.username = '...'
;
Výchozí hodnota je UNLIMITED .
Vezměte prosím na vědomí, že jinde mohou být uplatněna další omezení (firewall...), která mohou rušit. Takže si to raději udělejte konfigurovatelným , v případě, že se takové problémy objeví při nasazení vašeho produktu.
V systému Linux můžete ověřit maximální životnost fyzických připojení monitorováním TCP soketů připojených k vaší databázi. Spouštěl jsem níže uvedený skript na svém serveru (z pohledu DB je to klient hostitel), vyžaduje 1 argument, ip:port vašeho věšteckého uzlu, jak se objevuje ve výstupu netstat -tan (nebo vzor, pokud máte několik uzlů).
#!/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"
Pokud to spustíte a zastavíte pomocí ctrl-c během sleep měl by opustit smyčku a vyčistit dočasný adresář, ale to není 100% spolehlivé
Ve výsledcích žádný z portů by neměl ukazovat hodnotu přesahující 1800 sekund (tj. 30 minut), dejte nebo vezměte minutu. Viz příklad výstupu níže, první ukázka ukazuje 2 zásuvky nad 1800 s, jsou pryč o 10 s později.
------------ 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
Abyste to viděli, musíte skript spouštět déle než 30 minut, protože nezná stáří soketů, které existovaly dříve