4

私は賢いと思っていました。しかし、最近の発見に照らして、私はもうよくわかりません。ページのライフサイクル中に、データベースの相互作用がいくつも発生する可能性があります。背中合わせにあるものもあれば、広がるものもあります。そこで、HttpContext.ItemsディクショナリでSQL接続のインスタンスを存続させるオブジェクトを発明しました。その後、すべてのdbリクエストはこの接続を使用し、httpリクエストが終了すると、接続を適切に破棄します。接続が開いている数百ミリ秒を見ています。httpキャッシングが多い場合、使用可能な接続が不足することは問題ではありません。

ポイントは、新しい接続の確立による追加のラウンドトリップを防ぐことでした。しかし、接続プールの知識に出くわしたとき、それはSqlConnectionを保持することの有用性をかなり無効にすると思います。それともそうですか？

シナリオAはシナリオBと同じですか、パフォーマンスの面でですか？どちらをお勧めしますか？シナリオBはパフォーマンスの向上をもたらさず、接続が適切に破棄されない可能性があるいくつかのエッジケースのために、パフォーマンスを妨げる可能性さえありますか？例の疑似性を許してください、私はそれらをbarfで乱雑にしたくありません。

A

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();
4

2 に答える 2

7

セクションAのコードを使用してください。接続プールに任せてください。絶対に静的な状態を維持することは避けてくださいSqlConnection。接続プールはこのために設計されました。

参考までに、MSDNの記事をご覧ください。

SQL Server接続プール（ADO.NET）

于 2012-04-06T16:25:04.320 に答える
2

接続プールをオフにしない限り、コードでそれを行う意味はありません。

そして、それを行う前に、真剣に考える必要があります。それは極端な状況です。

接続プールは、この「永続的な」接続で対処しようとしている状況に対処するために考案されたため、実際には組み込みの最適化に干渉し、コードの量、複雑さ、および脆弱性を高めます。

于 2012-04-06T16:36:46.357 に答える