4
私は賢いと思っていました。しかし、最近の発見に照らして、私はそれ以上は確かではありません。ページライフサイクルの間、任意の数のデータベース相互作用によって可能性があります。背中合わせのものもあれば、広がるものもあります。だから、私はHttpContext.Items辞書にSQL接続のインスタンスを生きているオブジェクトを考案しました。すべてのdb要求はこの接続を使用し、http要求が終了すると接続を正しく破棄します。私たちは、接続が開かれる数百ミリ秒を見ています。多量のhttpキャッシュを使用すると、使用可能な接続が不足していることは懸念されません。SqlConnectionとプールは、kung-fooまたはfoo-barを開いたままにしていますか？
新しい接続の確立による追加のラウンドトリップを防止することがポイントでした。しかし、接続プーリングに関する知識が不足していたとき、SqlConnectionを保持することの有用性がかなり無効になったと思います。それとも？
シナリオAはシナリオBと同じですが、パフォーマンスは良いですか？どちらをお勧めしますか？シナリオBはパフォーマンスの向上をもたらさず、接続が適切に処理されない場合があるため、シナリオBはそれを妨げる可能性があります。例の疑似を許して、私はbarfでそれらを混乱させたくありません。
using (var connection = new SqlConnection(connectionString))
{
using (var command = new SqlCommand("...", connection))
{
... doing database stuff ...
}
}
... traversing the stack ...
using (var connection = new SqlConnection(connectionString))
{
using (var command = new SqlCommand("...", connection))
{
... doing database stuff ...
}
}
B
var connectionKeeper = new ConnectionKeeper();
// Add to the context items so it can be used anywhere
Context.Items.Add("Connection", connectionKeeper);
... traversing the stack ...
using (var command = new SqlCommand("...", connectionKeeper.Connection))
{
... doing database stuff
}
... traversing the stack ...
using (var command = new SqlCommand("...", connectionKeeper.Connection))
{
... doing database stuff
}
... traversing the stack ...
// The end of the request
sqlKeeper.Dispose();
合意されたSQLサーバーには接続プール機能が組み込まれていますので、接続を保持することについて心配する必要はありません。プールに魔法をかけましょう。 –
これは私が最近考えたものです。それを確認していただきありがとうございます。 – Levitikon
MSDNがADO.NETプーリングの記事を更新して、これに関する詳細をお伝えしたいと思います。この点について何度も議論しなければならないのは驚くべきことです。プールに仕事をさせてください！ – mafue