Kurze Antwort:keine (standardmäßig).
Für den Datensatz (um hier Details aufzunehmen, falls sich der Link ändert), sprechen wir über die Eigenschaft maxLifetime von HikariCP:
Diese Eigenschaft steuert die maximale Lebensdauer einer Verbindung im Pool. Eine aktive Verbindung wird nie stillgelegt, nur wenn sie geschlossen wird, wird sie entfernt. Wir empfehlen dringend, diesen Wert festzulegen, und er sollte mindestens 30 Sekunden kürzer sein als die von einer Datenbank oder Infrastruktur auferlegte Verbindungszeitbegrenzung. Ein Wert von 0 zeigt keine maximale Lebensdauer (unendliche Lebensdauer) an, natürlich abhängig von der Einstellung von IdleTimeout. Standard:1800000 (30 Minuten)
Meiner Erfahrung nach ist es gut, dass HikariCP das tut. Soweit ich das beurteilen kann, erzwingt Oracle standardmäßig keine maximale Lebensdauer für Verbindungen (weder auf der JDBC-Treiberseite (1), noch auf der Serverseite (2)). Also insofern die "infrastrukturbedingte Verbindungszeitbegrenzung " ist +unendlich -- und das war ein Problem für uns, da wir Probleme mit langlebigen Verbindungen beobachtet haben. Es bedeutet auch, dass jeder Wert "mindestens 30 Sekunden weniger ist ", einschließlich der Standardeinstellung :)
Ich vermute Die Verbindungsschicht unternimmt nichts dagegen, da sie sich auf die darüber liegende Poolschicht verlässt, um solche Dinge zu handhaben. Es war mit dem (inzwischen veralteten) impliziten Verbindungspool nicht möglich, und ich weiß nicht, ob UCP (der Ersatz) das tut, aber wenn Sie HikariCP verwenden, verwenden Sie diese nicht.
Jetzt, nach 30 Minuten (normalerweise nach vielen Wiederverwendungen für verschiedene Zwecke) für eine bestimmte Verbindung, schließt HikariCP sie und erstellt eine neue. Das hat sehr geringe Kosten und hat unsere Probleme mit langlebigen Verbindungen behoben. Wir sind mit dieser Standardeinstellung zufrieden, machen sie aber für alle Fälle trotzdem konfigurierbar (siehe 2 unten).
(1) OracleDataSource bietet keinen Konfigurationspunkt (Eigenschaft oder Systemeigenschaft), um dies zu steuern, und ich beobachtete unbegrenzte Lebensdauer.
(2) Für serverseitige Limits siehe Profilparameter IDLE_TIME . Zitieren dieser Antwort:
Oracle schließt standardmäßig keine Verbindung aufgrund von Inaktivität. Sie können ein Profil mit einer IDLE_TIME konfigurieren, damit Oracle inaktive Verbindungen schließt.
Um zu überprüfen, was der Wert von IDLE_TIME ist für Ihren Benutzer, indem Sie Antworten aus diesen Fragen und Antworten kombinieren:
select p.limit
from dba_profiles p, dba_users u
where p.resource_name = 'IDLE_TIME' and p.profile = u.profile and u.username = '...'
;
Der Standardwert ist UNLIMITED .
Bitte beachten Sie, dass an anderer Stelle (Firewall ... ) andere Beschränkungen durchgesetzt werden können, die möglicherweise stören. Machen Sie es also besser konfigurierbar , falls solche Probleme bei der Bereitstellung Ihres Produkts entdeckt werden.
Unter Linux können Sie die maximale Lebensdauer physischer Verbindungen überprüfen durch Überwachung von TCP-Sockets, die mit Ihrer Datenbank verbunden sind. Ich habe das folgende Skript auf meinem Server ausgeführt (aus DB-Sicht ist das der Client host), benötigt es 1 Argument, den ip:port Ihres Oracle-Knotens, wie es in der Ausgabe von netstat -tan erscheint (oder ein Muster, wenn Sie mehrere Knoten haben).
#!/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"
Wenn Sie das ausführen und es mit ctrl-c während sleep stoppen Mal sollte es die Schleife verlassen und das Temp-Verzeichnis bereinigen, aber das ist nicht 100 % narrensicher
In den Ergebnissen sollte keiner der Ports einen Wert anzeigen, der 1800 Sekunden überschreitet (dh 30 Minuten), geben oder nehmen Sie eine Minute. Siehe Beispielausgabe unten, erstes Beispiel zeigt 2 Steckdosen über 1800s, sie sind 10s später weg.
------------ 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
Sie müssen das Skript länger als 30 Minuten laufen lassen, um das zu sehen, da es das Alter der vorher existierenden Sockets nicht kennt
