还记得 .net 中的 SQL 连接状态吗？答案

【问题标题】：Remembering SQL connection state in .net?还记得 .net 中的 SQL 连接状态吗？
【发布时间】：2014-05-30 06:48:52
【问题描述】：

除此之外，connection.Close() 与 connection.Dispose() 是相同的 - 除了在已处置的连接上运行 Close() 会引发异常，而在已关闭的连接上运行 Close() 时会引发异常 - 没关系 - 我还有一个问题：

假设连接池已开启，（默认）-为什么记住连接的状态很重要？

我已阅读 this question here，它表明 - 避免打开和关闭连接可以节省性能。

这似乎是逻辑，但问题是连接实际上是从未关闭的！它只是标记为关闭。

即使我在 using 范围内使用它 - dispose 也只是关闭连接并将其放回池中。

即使我想要，我也不能让它打开 （因为我希望其他人使用它）。所以我不得不关闭/处理它。

Looking at Dapper 也实现了这种行为：

public static async Task<IEnumerable<T>> QueryAsync<T>(this...)
        {
         //...
            bool wasClosed = cnn.State == ConnectionState.Closed;
            using (var cmd = (DbCommand)command.SetupCommand(cnn, info.ParamReader))
            {
                try
                {
                    if (wasClosed) await ((DbConnection)cnn).OpenAsync()...
                  //...
                }
                finally
                {
                    if (wasClosed) cnn.Close();
                }
            }
        }

如你所见，这里实现了“记忆”。

nb，我已经向 Marc 询问了一个相关主题，即 - 为什么在 dapper 样本中他同时使用 GetClosedConneciton 和 GetOpenConnection 而我得到的答案是表明 - Dapper 可以处理这两种情况.然而，这个当前的问题是关于为什么它重新设置连接状态。

问题：

查看 Dapper 代码似乎是记住了状态并在操作后重新设置了状态。（我也从旧的 sqldataadapter 类中知道这种行为）

问题是 - 为什么？如果我有一个关闭的连接 - 那么，我需要打开它。伟大的。但为什么我必须按条件关闭它？为什么不总是关闭它？它不会影响性能，因为连接实际上并没有关闭 - 它只是返回到池中。

反过来 - 如果我有一个打开的连接，那么我会继续工作并保持它打开（嗯？？）

正如你可能看到的，我在这里遗漏了一些东西。有人可以解释一下吗？

【问题讨论】：

标签： c# .net connection-pooling dapper sqlconnection

【解决方案1】：

为什么不总是关闭它？

用户可能在该连接上做很多工作。它可能与交易相关联（关闭将孤立它）。它可能有临时表（关闭会破坏它们）或其他连接保留状态（SET 选项、模拟等）。

在此处关闭连接（如果它最初是打开的）将是一件不寻常且出乎意料的事情，具有多种令人讨厌的副作用。

【讨论】：

【解决方案2】：

如果您正在编写一个库函数，让消费者向您传递一个连接对象（任何风格）是有意义的，那么最安全的做法是尊重该连接：

如果您传递了一个打开的连接对象，请不要对它做任何假设，当然也不要在完成工作后关闭它 - 您不知道您的消费者已经用它做了什么或将用它做什么.
如果您传递了一个关闭的连接对象，那么您最好在尝试使用它之前将其打开，并且您应该在完成后关闭它 - 您知道您的消费者不能拥有例如针对关闭的连接打开的事务。

如果你的代码创建了一个连接对象，那么我总是建议将创建放在using 语句中，这样当你完成时它总是会关闭。

所以，我能想到的唯一剩下的事情就是仔细考虑编写你的函数，并弄清楚你的消费者传递连接对象是否有意义 - 如果你的工作应该总是单独执行，要求例如更有意义一个连接字符串，让您的代码完全控制连接。

【讨论】：