SQL接続の破棄に関連するこの質問を読みました。
私の質問は、単純に SQL 接続を閉じて、それを破棄しないのはどれほど悪いことですか? 単純に閉じられるが破棄されることのない関数があり、1 日に 1000 回使用されます。そのまま閉じた方がいいですか、それとも閉じて処分した方がよいでしょうか。
dispose() も接続を閉じることは承知していますが、close が接続を破棄しない理由を知りたいです。
SQL接続の破棄に関連するこの質問を読みました。
私の質問は、単純に SQL 接続を閉じて、それを破棄しないのはどれほど悪いことですか? 単純に閉じられるが破棄されることのない関数があり、1 日に 1000 回使用されます。そのまま閉じた方がいいですか、それとも閉じて処分した方がよいでしょうか。
dispose() も接続を閉じることは承知していますが、close が接続を破棄しない理由を知りたいです。
接続に関する重要なことは、接続プールに戻されるように接続を閉じることです。
そのため、接続を閉じることと再利用しないことについて規律がある限り、接続を破棄することと閉じることの間にほとんど違いはありません。
ただし、接続の作成をusing
ステートメントでラップする習慣があるということは、接続を閉じることを決して忘れないことを意味します。
従うのは一般的に良いイディオムです。実装するオブジェクトの作成はステートメントでIDisposable
ラップする必要があります。そのようなイディオムとして、接続を使用するのも良いイディオムです。using
対象外かどうかによります。存在する場合は、とにかく閉じられ、接続プールが返されます (無効にしていない場合)。したがって、クローズを暗黙的または明示的に呼び出すと、意図が明確になり、その接続がプールで再利用できるようになります。
アイデアは、開発者にデータベースにすばやく出入りするよう説得することでした。少額取引が多い。古いスタイルでは、接続を開いてから隠して、他の誰もアクセスできないようにします。
接続プーリングが using 句にある場合、Create、open、Close と同等です。オフの場合、using 句は create、open、close、Dispose と同等です。
どちらのシナリオでも、本当の取引は、それが範囲外になることを確認することです. 非常にまれな状況を除いて、接続はローカル参照であり、この特定の用途の寿命を持つ必要があります。通常、実行時にインスタンスを作成して、インスタンスのメインフォームのプロパティにすることはありません。