HikariCP:Какви изчаквания на ниво база данни трябва да се имат предвид, за да се зададе maxLifetime за Oracle 11g

Кратък отговор:няма (по подразбиране).

За протокола (за да включим подробности тук, в случай че връзката се промени), говорим за свойство maxLifetime на HikariCP:

Това свойство контролира максималния живот на връзка в пула. Връзката, която се използва, никога няма да бъде прекратена, само когато бъде затворена, ще бъде премахната. Настоятелно препоръчваме да зададете тази стойност и тя трябва да бъде с поне 30 секунди по-малко от която и да е база данни или инфраструктура, наложено времево ограничение за връзка. Стойност 0 показва липса на максимален живот (безкраен живот), разбира се, в зависимост от настройката idleTimeout. По подразбиране:1800000 (30 минути)

Според моя опит е добре, че HikariCP прави това. Доколкото мога да разбера по подразбиране Oracle не налага максимален живот на връзки (нито от страна на драйвера на JDBC (1), нито от страна на сървъра (2)). Така че в това отношение „наложеното от инфраструктурата времево ограничение за връзка " е +безкрайност -- и това беше проблем за нас, тъй като наблюдавахме проблеми с дълготрайните връзки. Това също означава, че всяка стойност е "поне 30 секунди по-малко ", включително по подразбиране :)

предполагам слоят на свързване не прави нищо по въпроса, защото разчита на горния пул слой да се справи с такива неща. Не беше възможно с (вече отхвърлен) имплицитен пул за връзки и не знам дали UCP (замяната) прави това, но ако използвате HikariCP, не ги използвате.

Сега, след 30 минути (обикновено след много повторни употреби за различни цели) за дадена връзка, HikariCP я затваря и създава нова. Това има много малка цена и поправи проблемите ни с дълготрайни връзки. Ние сме доволни от това по подразбиране, но все пак го правим конфигурируем за всеки случай (вижте 2 по-долу).

(1) OracleDataSource не предлага никаква конфигурационна точка (свойство или системно свойство), която да контролира това и аз наблюдавах безкраен живот.

(2) За ограничения от страна на сървъра вижте параметъра на профила IDLE_TIME . Цитирайки този отговор:

Oracle по подразбиране няма да затвори връзка поради неактивност. Можете да конфигурирате профил с IDLE_TIME, за да накарате Oracle да затвори неактивни връзки.

За да проверите каква е стойността на IDLE_TIME за вашия потребител, комбинирайки отговори от тези въпроси и отговори:

select p.limit
from dba_profiles p, dba_users u
where p.resource_name = 'IDLE_TIME' and p.profile = u.profile and u.username = '...'
;

Стойността по подразбиране е UNLIMITED .

Моля, имайте предвид, че може да има други ограничения, наложени другаде (защитна стена...), които могат да пречат. Така че по-добре го направете конфигурируем , в случай че такива проблеми бъдат открити, когато внедрите продукта си.

В Linux можете да проверите максималния живот на физическите връзки чрез наблюдение на TCP сокети, свързани към вашата база данни. Стартирах скрипт по-долу на моя сървър (от гледна точка на DB това е клиентът хост), отнема 1 аргумент, ip:port на вашия оракул възел, както се появява в изхода на netstat -tan (или шаблон, ако имате няколко възела).

#!/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"

_{Ако го стартирате и го спрете с ctrl-c по време на sleep време, трябва да излезе от цикъла и да почисти временната директория, но това не е 100% сигурно}

В резултатите нито един от портовете не трябва да показва стойност, която надвишава 1800 секунди (т.е. 30 минути), дайте или отделете минута. Вижте примерния изход по-долу, първата проба показва 2 сокета над 1800-те, те са изчезнали 10-те секунди по-късно.

------------ 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

_{Ще трябва да стартирате скрипта за повече от 30 минути, за да видите това, защото той не знае възрастта на сокети, които са съществували преди}