接続プールの問題

何が起こっているかを説明するためのイベントの流れは次のとおりです。

1. 接続は呼び出し元（アプリケーションまたは接続プール）によって要求および使用されます
2. 接続を再利用できるように、呼び出し元はその参照を保持します
3. 発信者が非アクティブな期間を通過します（たとえば、夜間の開発システムや週末のQAシステム）。
4. そのデータベース接続が使用されていない場合、データベースは接続がアイドル状態であると見なします。アイドル状態であるため、一定時間（MySQLのデフォルトは8時間）が経過すると、データベースは接続を閉じます。
5. 発信者はまだ接続へのハンドルを持っており、発信者が接続を再度使用しようとすると、接続が閉じられていることに不快感を覚えます。

autoReconnect =trueが機能し、接続の有効性をテストするプールが機能する理由は、この状況で接続をテストし、この状況が発生した場合に再試行するように呼び出し側システムに指示しているためです。

検証クエリがパフォーマンスに影響を与えるかどうかについて：理論的には、接続を使用して何かを実行しています。実際には、何かが非常に些細なことなので、システム全体のコンテキストではその影響は無視できます。

[編集]

この場合、Apache DBCPは接続に接続されている接続プールですが、呼び出しのたびにDBCPが接続を閉じないようにする必要があります。接続プールのポイントは、接続の作成にコストがかかるため、次の呼び出しに備えて接続を準備しておくことです。プールによって維持される接続オブジェクトは、実際のデータベース接続によって支えられており、データベースは、アイドルタイムアウト期間の後にその実際の接続を閉じるものです。アイドル状態の接続を閉じるためのタイムアウトは、接続プールではなくデータベースで構成されていることに注意してください。このため、DBCPは、実際に接続を試みない限り、接続が閉じられているかどうかを知る方法がありません。そのため、検証クエリが必要です。

DBCPの構成の詳細については、構成ページ を参照してください。 およびAPIドキュメント> 。