c# - SqlConnection 和Pool，是保持打开的连接kung-foo 还是foo-bar？

Question

我以为我很聪明。但鉴于最近的发现，我不再那么确定了。在页面生命周期中，可以进行任意数量的数据库交互。有的背靠背，有的分散开来。所以我发明了一个对象，它使 SQL 连接的实例在 HttpContext.Items 字典中保持事件状态。然后每个数据库请求都使用此连接，当 http 请求结束时，我会正确处理该连接。我们正在查看连接将打开的几百毫秒，并且使用一些繁重的 http 缓存，用完可用连接不是问题。

重点是防止由于建立新连接而导致的额外往返。但是当我偶然发现连接池的知识时，我认为它完全没有保留 SqlConnection 的用处。或者是吗？

在性能方面，场景 A 是否与场景 B 相同？你会推荐哪个？场景 B 是否没有提供任何性能提升，甚至可能因为连接可能无法正确处理的某些边缘情况而阻碍它？请原谅示例中的伪造，我不想让它们变得困惑。

一个

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

Answer 1

使用 A 部分中的代码。请让连接池完成它的工作。不惜一切代价避免保留静态 SqlConnection。连接池就是为此而设计的。

这里有一篇 MSDN 文章供您引用。

SQL Server Connection Pooling (ADO.NET)