私の Web アプリケーションでは、データベースを多用しています。
データベース接続を必要とするすべてのサーブレットが継承する抽象サーブレットがあります。その抽象サーブレットはデータベース接続を作成し、継承するサーブレットがロジックを実行するためにオーバーライドする必要がある抽象メソッドを呼び出してから、接続を閉じます。アプリケーションのユーザー数と操作数が非常に限られているため、接続プーリングは使用しません。
私の質問は、継承するサーブレットが作成するResultSets、PreparedStatements、およびs を閉じない場合、それらを作成する s が常に閉じている場合に起こりうる最悪の事態は何ですか?StatementConnection
Statement#close()の javadoc には次のように書かれています。
注: Statement オブジェクトが閉じられると、現在の ResultSet オブジェクトが存在する場合は、それも閉じられます。
そのため、Statement を常に適切なタイミングで閉じる限り、ResultSet を閉じることを心配する必要はありません。
Connection#close()の javadoc は、対応する保証を行いませんが、次のように述べています。
この Connection オブジェクトのデータベースと JDBC リソースが自動的に解放されるのを待つのではなく、ただちに解放します。
これは、ステートメントがクローズされることを暗示していると合理的に解釈できます。オープンソースの jTDS ドライバーを見て、有名で高価な商用データベースのドライバーを覗いてみると、まさにそれを行っていることがわかります。
接続を閉じると、関連するステートメント、結果セット、およびその他の関連するオブジェクトが閉じられると確信しています。ただし、これらはすべて、接続が閉じられるまでクライアントとデータベース サーバーの両方でリソースを消費します。
あなたの場合、すぐに接続を閉じることがわかっている場合は、おそらくあまりリスクを冒すことはありませんが、これをベストプラクティスと見なすべきではないと思います.
ただし、これは現在の設定でのみ有効です。Statements とResultSetsを閉じていないため、アプリケーションが変更されるときに問題が発生する可能性があります。
接続プーリングを使用したくない場合でも、データベース接続を開くのは安くないため、ユーザー/操作が少ない場合でも、それは悪い考えだと思います。したがって、コンテキスト接続プールであっても、システムの応答性を高めるのに役立つ場合があります。
ガベージコレクションについてのメモ。接続を閉じる前に、未使用の Statement または ResultSetを GCすることができます。ただし、ファイルなどのシステム リソースや、より一般的には Java 以外のリソース (データベース サーバー上のカーソルなど) を解放する場合は、JVM GC に依存するべきではありません。たとえば、クライアント アプリケーションが多数の ResultSet を開き、割り当てられたヒープ メモリのごく一部しか使用しない場合、データベース サーバーが開かれたカーソルによって窒息している間、GC は起動しません。
私の知る限り、ファイルハンドルの拘束、特定のステートメントに関連付けられた結果セットを保持するために必要なリソースなどにより、データベースサーバーのリソースが使い果たされることになります。スマートなドライバー/データベースの実装があり、すぐに接続が閉じられると、関連するすべてのリソースが解放されますが、それは仕様の一部ではないため、最終的には長期的にはあなたを噛む可能性があります. オーバーライド クラスが、使用する結果セットとステートメントを閉じることができない理由はありますか?
アプリケーションが関係しているのは、データベースへの接続だけではありません。危機に瀕している他のリソースがあります。
自分で解放しなくても、ある時点で解放されますが、解放できる場合は解放する必要があります。