ただし、トランザクションの終了後に、トランザクション・マネージャーが接続を閉じ、その接続をフリー・プールに戻すことによって、マイナスの効果が生じます。アプリケーションは、あるトランザクションで接続を取得し、その接続を別のトランザクションで使用しようとしてもできなくなります。 アプリケーションがそうしようとしても、接続がすでに閉じられているので、StaleConnection 例外がスローされます。
孤立した接続、または自動接続クリーンアップによって使用不可にされた接続を使用しようとすると、StaleConnection 例外により、すでに接続プールに戻された接続をアプリケーションが使用しようとしたことが示されます。 これは、実際に接続に関する問題があることを示しているわけではありません。 しかし、その他の StaleConnection 例外の場合は、データベースへの接続がうまくいかなかったか、あるいは失効 したことを示しています。 接続は、一度失効するとリカバリーできないので、 プールには戻さず、完全に閉じる必要があります。
データベースへの接続が失効すると、その接続での操作の結果、JDBC Driver から SQL 例外が出されます。 SQL 例外は、どちらかと言えば一般的な例外であるため、これには、例外の意味の判別に使用できる状態およびエラー・コードの値が含まれています。 しかし、これらの状態およびエラー・コードの意味は、 データベースのベンダーによって異なります。 この接続プール・ランタイムには、SQL 状態とエラー・コードが、サポートされているデータベース・ベンダーごとの StaleConnection 例外を示す、マッピングが保持されています。 接続プール・ランタイムは、SQL 例外をキャッチすると、この SQL 例外が、使用中のデータベース・サーバーに対する StaleConnection 例外と考えられるかどうかを確認します。
失効した接続からのリカバリーは、 アプリケーション・サーバー・ランタイムとアプリケーション開発者が共同で行う作業です。 アプリケーション・サーバーの観点では、 接続プールは、その PurgePolicy 設定に基づいてパージされます。
アプリケーションでは、StaleConnection 例外を明示的にキャッチする必要はありません。 これは、アプリケーションはすでに java.sql.SQL 例外をキャッチする必要があり、StaleConnection 例外は SQL 例外を拡張するので、StaleConnection 例外は SQL 例外の作成が宣言されているどのメソッドからでも出すことが可能であり、通常の catch ブロックで自動的にキャッチされるためです。 ただし、StaleConnection 例外を明示的にキャッチすると、アプリケーションが不良接続からリカバリーできるようになります。 アプリケーション・コードで StaleConnection 例外をキャッチすると、明示的な例外処理のステップが実行されます。