ASP.NET アプリケーションに接続プールのメモリ リークの問題があるとします (たとえば、接続が正しく閉じられていない場合)。
アプリケーション プールをリサイクルすると、接続プールがクリアされますか (したがって、より多くの接続を確立できますか)?
ガベージ コレクターが接続を削除するまで接続がメモリに残っている場合、アプリケーション プールが再起動されたときに発生しますか (または、それを超えて接続を維持できますか)? また、ガベージ コレクターがいつでもそれらをクリーンアップできることも理解していますが、それらはまだ使用されており、リセットまたはアプリケーション プールの再起動まで収集できませんか?
接続を正しく管理するためにコードを修正することが最終目標であることは明らかなシステムをレビューしており、ガベージ コレクション/アプリケーション プール プロセスについて理解を深めようとしています。
はい、アプリ プールをリサイクルすると、アプリケーションの実行を担当する IIS プロセスが強制終了され、再起動されます。プロセスが終了するため、この時点ですべてのリソースが解放されます。
プロセスが再起動されず、単にハンドルがリークする場合、ガベージ コレクターは最終的にハンドルをクリーンアップします。ただし、これが発生する前に、リークしているリソースのハンドルが不足する可能性があります。これが、これらのオブジェクトで (できれば "using" パターンによって) Dispose() を呼び出すことが重要である理由です。これにより、ガベージ コレクターがリソースに到達したときではなく、アプリがそれらの処理を完了するとすぐにリソースが解放されます。
接続プールは、データベース接続のキャッシュです。アプリケーション プールは、1 つ (または複数) のワーカー プロセスです。したがって、アプリケーション プールをシャットダウンすると、ワーカー プロセスがシャットダウンされ、新しいワーカー プロセスが開始されます。これにより、プールが破棄され、接続プール内のすべての接続が閉じられます。
接続で Close または Dispose を呼び出さず、ガベージ コレクターに依存している場合、接続がプールに返される場合と返されない場合があります。接続がまだ有効で、最大プールサイズに達した場合にのみ、プールに追加されると思います。おそらくご存知のように、これをガベージ コレクターに頼るべきではありません。接続が Disposed であることを確認する簡単な方法は、コード ブロックの最後で Dispose を自動的に呼び出す using ステートメントを使用することです。
ADO.NET 2.0 には、プールをプログラムで管理するための新しいメソッド、ClearAllPools と ClearPool があります。これは、すべてのデータ アクセス コードを修正できるまで、問題の解決に役立つ可能性があります。