前提知識
-
HikariCPとは
高性能なDB接続プールライブラリ -
接続プールとは
DBへの接続を効率的に管理するために使用されます。必要なときにすぐに使用できる接続をプール（プール内に保持）します。 -
データベース接続とHikariCPプールの初期化の流れ
アプリケーション起動時にHikariCPが接続プールを初期化し、データベースとの接続を確立します。 -
接続の再取得
プール内の接続が無効と判断された場合、HikariCPはその接続を閉じ、新たな接続を確立しようとします。
接続失敗時の挙動パターン
接続失敗時の挙動には主に以下の二つのパターンがあります：
- 接続プールの初期化時（アプリケーションの立ち上げ時）
- アプリケーションのランタイム中の再接続
接続プール内のDBへの接続が無効になった場合の再接続はどうするの？
接続プール内で新しい接続の取得が失敗した場合、HikariCPは内部の設定とロジックに基づいて再接続を試みます。具体的な挙動は以下の設定によって制御されます：
spring.datasource.hikari.idleTimeout=600000 # 10分
spring.datasource.hikari.connectionTimeout=30000 # 30秒
spring.datasource.hikari.initializationFailTimeout=0
設定項目の解説（application.properties）
-
idleTimeout
プール内の個々の接続のアイドル状態を管理し、指定時間（ここでは10分）を超えたら接続を閉じます。 -
connectionTimeout
新たな接続の取得に失敗した場合、指定時間（ここでは30秒）待機し、接続が確立されなかったらエラーを出力します。 -
initializationFailTimeout
接続プールの初期接続に失敗した場合、指定時間内（ここでは0）で再接続を試みます。
疑問が・・・
アプリケーションのランタイム時（接続プールが初期化されていてDB接続が確立されている状態）にDBのサービスを終了し、以下の挙動を比較しました：
-
initializationFailTimeoutを設定値に入れなかった場合
再接続処理が行われなかった。 -
initializationFailTimeoutを設定値に入れた場合
再接続処理が行われた。
上記の状況では接続プール内の接続が失敗しているため、initializationFailTimeoutの値は関係ないと考えていましたが、実際には再接続が行われました。
結論
ランタイム中の再接続試行はinitializationFailTimeoutに依存しないといわれているけど、実際はランタイム中の再接続試行はinitializationFailTimeoutに依存している。（気がする。。）
詳細な解説
HikariCPの再接続試行設定について
HikariCPは、接続プールの管理において以下の二つの主要なタイミングで接続の再試行を行います：
- 接続プールの初期化時（アプリケーションの起動時）
- ランタイム中の接続管理時
初期接続取得の失敗
初期接続の取得に失敗した場合、initializationFailTimeoutの設定に基づいて挙動が決まります。
-
設定値が0の場合
初期接続取得に失敗してもプールの初期化を継続し、バックグラウンドで再試行を行います。 -
設定値が正の値の場合
指定された時間内（例: 30秒）に初期接続が確立できなければ、初期化を失敗させ、アプリケーションの起動を中断します。 -
設定値が負の値の場合
永続的に再接続を試み、初期化を継続します。
なぜinitializationFailTimeoutがランタイム中の再接続に影響を与えたのかがわからない。。
答え持っている方いらっしゃいましたら教えてください。