记住.net中的SQL连接状态？

Question

除了旧的已知事实,即connection.Close()vs connection.Dispose()是相同的 - 除了在关闭的连接上运行时,Close()在已处理的连接上运行引发异常Close()- 是的 - 我还有一个问题:

假设连接池已打开,(默认) - 为什么记住连接状态很重要？

我在这里读到了这个问题,它表明 - 避免打开和关闭连接可以节省性能.

这似乎是逻辑,但问题是连接永远不会被关闭!它只标记为关闭.

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

即使我想要,我也不能让它开放(因为我希望其他人使用它).所以我不得不关闭/处理它.

看看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,我已经问马克有关相关主题是-为什么短小精悍的样品中,他同时使用GetClosedConneciton,并GetOpenConnection和我得到的回答是展现-那小巧玲珑的可以处理这两种情形.然而,当前的问题是关于为什么重新设置 连接状态.

题 :

看看Dapper代码,它似乎记得状态并在操作后重新设置状态.(我也从旧的sqldataadapter类知道这种行为)

问题是 - 为什么？如果我有一个封闭的连接 - 那么,我需要打开它.大.但为什么我必须按条件关闭呢？为什么不总是关闭它？它不会损害性能,因为连接实际上并未关闭 - 它只返回池中.

反过来 - 如果我有一个开放的连接,那么我会工作并保持打开(呵呵??)

你可能已经看到了,我在这里遗漏了一些东西.有人可以光明吗？

Answer 1

如果你正在编写一个库函数,消费者可以通过它传递一个连接对象(无论什么样的味道),那么最安全的做法就是尊重这个连接:

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

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

因此,我能想到的唯一剩下的事情就是仔细考虑编写函数并确定消费者是否有理由通过连接对象 - 如果你的工作应该总是单独执行,那么会更多要求例如连接字符串和代码完全控制连接的意义.

Answer 2

为什么不总是关闭它？

用户可能正在对该连接进行大量工作.它可能与一个事务相关联(关闭它会孤立它).它可能有临时表(关闭会破坏它们),或其他连接保留状态(SET选项,模拟等).

在这里关闭连接(如果它最初打开)将是一个不寻常和意想不到的事情,有多个令人讨厌的副作用.