Krótka odpowiedź:brak (domyślnie).
Dla porządku (aby uwzględnić tutaj szczegóły w przypadku zmiany linku), mówimy o właściwości maxLifetime HikariCP:
Ta właściwość kontroluje maksymalny czas życia połączenia w puli. Używane połączenie nigdy nie zostanie wycofane, a dopiero po zamknięciu zostanie usunięte. Zdecydowanie zalecamy ustawienie tej wartości, która powinna być co najmniej o 30 sekund krótsza od limitu czasu połączenia narzuconego przez bazę danych lub infrastrukturę. Wartość 0 oznacza brak maksymalnego czasu życia (nieskończony czas życia), oczywiście z zastrzeżeniem ustawienia idleTimeout. Domyślnie:1800000 (30 minut)
Z mojego doświadczenia wynika, że to dobrze, że HikariCP to robi. O ile wiem, domyślnie Oracle nie wymusza maksymalnego czasu życia połączeń (ani po stronie sterownika JDBC (1), ani po stronie serwera (2)). W związku z tym „narzucony przez infrastrukturę limit czasu połączenia „ to +nieskończoność – i to był dla nas problem, ponieważ zaobserwowaliśmy problemy z długotrwałymi połączeniami. Oznacza to również, że każda wartość jest „co najmniej 30 sekund krótsza ", w tym domyślne :)
przypuszczam warstwa połączenia nic z tym nie robi, ponieważ liczy na to, że warstwa puli powyżej poradzi sobie z takimi rzeczami. Nie było to możliwe z (teraz przestarzałą) niejawną pulą połączeń i nie wiem, czy UCP (zamiennik) to robi, ale jeśli używasz HikariCP, nie używasz ich.
Teraz, po 30 minutach (zwykle po wielu ponownym użyciu do różnych celów) dla danego połączenia, HikariCP zamyka je i tworzy nowe. To wiąże się z bardzo niewielkimi kosztami i naprawiło nasze problemy z długotrwałymi połączeniami. Jesteśmy zadowoleni z tego ustawienia domyślnego, ale nadal umożliwiamy jego konfigurację na wszelki wypadek (patrz 2 poniżej).
(1) OracleDataSource nie oferuje żadnego punktu konfiguracji (właściwości lub właściwości systemu) do kontrolowania tego i zaobserwowałem nieskończona żywotność.
(2) Aby zapoznać się z ograniczeniami po stronie serwera, zobacz parametr profilu IDLE_TIME . Cytując tę odpowiedź:
Oracle domyślnie nie zamyka połączenia z powodu braku aktywności. Możesz skonfigurować profil z IDLE_TIME, aby spowodować zamknięcie nieaktywnych połączeń przez Oracle.
Aby sprawdzić, jaka jest wartość IDLE_TIME dla użytkownika, łącząc odpowiedzi z tego pytania i odpowiedzi:
select p.limit
from dba_profiles p, dba_users u
where p.resource_name = 'IDLE_TIME' and p.profile = u.profile and u.username = '...'
;
Wartość domyślna to UNLIMITED .
Pamiętaj, że gdzie indziej mogą obowiązywać inne ograniczenia (zapora sieciowa... ), które mogą przeszkadzać. Więc lepiej, aby był konfigurowalny , w przypadku wykrycia takich problemów podczas wdrażania produktu.
W systemie Linux możesz zweryfikować maksymalny czas życia połączeń fizycznych poprzez monitorowanie gniazd TCP podłączonych do Twojej bazy danych. Uruchomiłem poniższy skrypt na moim serwerze (z punktu widzenia bazy danych jest to klient host), przyjmuje 1 argument, ip:port twojego węzła Oracle, tak jak jest to widoczne w danych wyjściowych netstat -tan (lub wzór, jeśli masz kilka węzłów).
#!/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"
Jeśli uruchomisz to i zatrzymasz za pomocą ctrl-c podczas sleep czas, powinien wyjść z pętli i wyczyścić katalog tymczasowy, ale nie jest to w 100% niezawodne
W wynikach żaden z portów nie powinien pokazywać wartości przekraczającej 1800 sekund (tj. 30 minut), daj lub weź minutę. Zobacz przykładowe wyjście poniżej, pierwsza próbka pokazuje 2 gniazda powyżej 1800 roku, zniknęły 10 sekund później.
------------ 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
Musisz uruchomić skrypt przez ponad 30 minut, aby to zobaczyć, ponieważ nie zna on wieku gniazd, które istniały wcześniej
