プールされた接続をアプリケーションに返却する前に、アプリケーションサーバは接続が有効か検証できます。この検証によって、データベースがネットワーク障害かデータベース・サーバ障害により利用不可となった場合、その接続をプールから破棄し、再度プールから接続を獲得して有効な接続を返却します。プールに有効な接続が存在しなかった場合、データベースから新たな接続を獲得するため、データベース接続を再確立できます。
接続検証が有効の場合には、以下が設定できます。
検証方法
テーブル名
すべての障害で
これらの項目のチューニングは、asadminコマンドで設定できます。
JDBC接続プールを作成する時は、「9.1.14.1 create-jdbc-connection-poolサブコマンド」を参照してください。
JDBC接続プールの項目を更新する時は、「9.1.4 定義項目参照/更新」と「7.5.1 JDBC接続プールの定義項目」を参照してください。
また、接続検証が有効の場合には、アプリケーションサーバは以下の契機で接続検証を実効します。
接続検証の実行契機
アイドルタイムアウトの間隔で定期的に接続検証を実行します。
接続を生成してからプールへ格納する前(B1)とプールから取得後にアプリケーションへ返却する前(B2)の2種類の契機で接続検証が実行されます。
アプリケーションサーバはDBとの接続確立の直後、プールへ格納する前に事前に接続検証を実行します。
接続検証に失敗した場合、接続生成に失敗と判断し、アプリケーションへ例外を返却します。
プール内から取得した接続をアプリケーションへ返却する前に、接続検証を実行します。
プールサイズのスケールアップにより新規作成された接続のうちアプリケーションへ返却する接続に対しては、検証不要のため接続検証をスキップします。プール初期化時に生成される接続は、プール内から取得した接続と見なし接続検証を実行します。
「すべての障害で」が有効の時
「すべての障害で」の処理で一時的にプール内の接続が0になるのを補うために新たな接続を生成します。もしこの時点で再確立の処理が完了し未使用な接続があれば、置き換えて(破棄して)要求元へ接続を返却します。
「すべての障害で」が無効の時
検証失敗の接続を削除し、プールから次の接続を取り出して再度接続検証を実施します。プール内の使用されていない接続がすべて接続検証に失敗した場合の動作は、「接続要求に応じたプールサイズのスケールアップ」を参照してください。
注意
Interstage側のプーリング機能が無効の場合、接続を生成してからプールへ格納する前(B1) のタイミングのみで接続検証が実行されます。
接続障害と判断される条件
「すべての障害で」が有効の場合に接続障害と判断される条件は、以下です。
接続検証の実行時にJDBCドライバから例外が返却された場合
注意
データベース接続を再確立できなかった場合には、例外が返却されます。
自動的に再接続を行うことで、データベースで異常が発生しても業務継続ができるため、接続検証を有効にすることがお勧めですが、アプリケーションでgetConnectionメソッドを実行して接続プールから接続を獲得する時にも検証を行うため、性能オーバーヘッドが発生します。接続検証が不要な場合で、処理性能を向上させたい場合には、必要に応じて接続検証を無効にしてください。
接続検証を無効に設定した場合、検証方法およびテーブル名の指定も無効となります。
