Kort antwoord:geen (standaard).
Voor de goede orde (om hier details op te nemen voor het geval de link verandert), we hebben het over eigenschap maxLifetime van HikariCP:
Deze eigenschap bepaalt de maximale levensduur van een verbinding in de pool. Een in gebruik zijnde verbinding wordt nooit buiten gebruik gesteld, alleen wanneer deze wordt gesloten, wordt deze verwijderd. We raden u ten zeerste aan deze waarde in te stellen en deze moet ten minste 30 seconden korter zijn dan een door de database of infrastructuur opgelegde verbindingstijdlimiet. Een waarde van 0 geeft aan dat er geen maximale levensduur is (oneindige levensduur), uiteraard afhankelijk van de idleTimeout-instelling. Standaard:1800000 (30 minuten)
In mijn ervaring is het een goede zaak dat HikariCP dat doet. Voor zover ik weet Standaard legt Oracle geen maximale levensduur op voor verbindingen (noch aan de JDBC-stuurprogrammakant (1), noch aan de serverkant (2)). Dus in dit opzicht is de "door de infrastructuur opgelegde verbindingstijdslimiet " is +oneindig -- en dat was een probleem voor ons, omdat we problemen met langlevende verbindingen hebben waargenomen. Het betekent ook dat elke waarde "minstens 30 seconden minder is ", inclusief de standaard :)
Ik veronderstel de verbindingslaag doet hier niets aan omdat het op de poollaag erboven rekent om dergelijke dingen af te handelen. Het was niet mogelijk met (nu verouderde) impliciete verbindingspool, en ik weet niet of UCP (de vervanging) dat doet, maar als je HikariCP gebruikt, gebruik je die niet.
Nu, na 30 minuten (meestal na veel hergebruik voor verschillende doeleinden) voor een bepaalde verbinding, sluit HikariCP deze en maakt een nieuwe aan. Dat kost heel weinig, en loste onze problemen met langlevende verbindingen op. We zijn blij met die standaard, maar maken het nog steeds configureerbaar voor het geval dat (zie 2 hieronder).
(1) OracleDataSource biedt geen configuratiepunt (eigenschap of systeemeigenschap) om dat te controleren, en ik waargenomen oneindige levensduur.
(2) Voor server-side limieten, zie profielparameter IDLE_TIME . Dit antwoord citerend:
Oracle zal standaard een verbinding niet sluiten vanwege inactiviteit. U kunt een profiel configureren met een IDLE_TIME om ervoor te zorgen dat Oracle inactieve verbindingen sluit.
Om te controleren wat de waarde is van IDLE_TIME voor uw gebruiker, door antwoorden uit deze Q&A te combineren:
select p.limit
from dba_profiles p, dba_users u
where p.resource_name = 'IDLE_TIME' and p.profile = u.profile and u.username = '...'
;
Standaardwaarde is UNLIMITED .
Houd er rekening mee dat er elders (firewall... ) andere limieten kunnen zijn die interfereren. Je kunt het dus beter configureerbaar maken , voor het geval dergelijke problemen worden ontdekt wanneer u uw product implementeert.
Op Linux kunt u de maximale levensduur van fysieke verbindingen verifiëren door de TCP-sockets te controleren die op uw database zijn aangesloten. Ik heb het onderstaande script op mijn server uitgevoerd (vanuit het DB-oogpunt is dat de client host), er is 1 argument voor nodig, de ip:port van uw orakelknooppunt, zoals het wordt weergegeven in de uitvoer van netstat -tan (of een patroon als je meerdere knooppunten hebt).
#!/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"
Als je dat uitvoert en stopt met ctrl-c tijdens sleep tijd, zou het de lus moeten verlaten en de tijdelijke map moeten opschonen, maar dit is niet 100% onfeilbaar
In de resultaten mag geen van de poorten een waarde tonen die groter is dan 1800 seconden (dwz 30 minuten), geef of neem een minuut. Zie voorbeelduitvoer hieronder, eerste voorbeeld toont 2 sockets boven 1800s, ze zijn 10s later verdwenen.
------------ 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
Je moet het script meer dan 30 minuten laten lopen om dat te zien, omdat het de leeftijd van sockets die eerder bestonden niet kent