相关疑难解决方法(0)

试图通过发出"sp_reset_connection"来理解Sql Profiler的含义.

我有以下,"exec sp_reset_connection"行后跟BatchStarting和Completed,

RPC:Completed       exec sp_reset_connection
SQL:BatchStarting   SELECT [c].[TestID] AS [TestID], [c].[Description] AS [Description] FROM [dbo].[Test] AS [c]
SQL:BatchCompleted  SELECT [c].[TestID] AS [TestID], [c].[Description] AS [Description] FROM [dbo].[Test] AS [c]    

基本上第一行"exec sp_reset_connection"意味着整个过程(我的连接被打开,选择stmt运行,然后连接关闭并释放回池)刚刚发生？或者我的联系仍处于开放阶段.

而且,为什么sp_reset_connection在我自己的select语句之前执行,不应该在用户的sql之后复位吗？

我想知道有什么方法可以更详细地了解连接何时打开和关闭？

通过查看"exec sp_reset_connection",这是否意味着我的连接已关闭？

我想知道使用EF上下文sp_getapplock和会话所有者类型的风险/安全性.基于文档,我的理解是会话所有者意味着如果在此之前没有明确释放,则会话结束时将释放锁定.我假设这也意味着连接结束.

我已经将这一切都用于事务拥有的锁,但这带来了其他问题和复杂性,所以我想知道如何使用会话拥有的锁以及它将如何或不会与行为DbContext及其连接发生冲突处理.

我不是100%确定DbContext默认情况下是如何工作的,无论是使用池还是每个上下文实例都打开并关闭它自己的连接(我读过的文档似乎暗示后者).对于这个问题,假设我没有做任何关于连接管理的事情(我很少这样做),所以EF正在处理它,或处理它的任何处理.

如果我创建一个DbContext实例,抓取连接,执行SQL来创建一个会话拥有的锁,正常使用上下文,不释放锁并处理上下文,这会正常工作吗？(实际上,这将是一个IDisposable包装,以防止这种情况,但问题仍然存在.)

为了说明不好:

using (var ctx = new MyContext()) {
    var conn = ctx.Database.Connection.Open();
    conn.ExecuteSqlSomehow("sp_getapplock blahblah");
    try {
        // Lots of queries, savechanges, etc.
    } finally {
        // Oops I forgot to conn.ExecuteSql("sp_release the lock");
    }
}

await WatchMovieAsync();

using (var ctx = new MyContext()) {
    // Can this reuse the same connection, session and/or lock?
}

问题:

1. 在处理实例后,另一个上下文可以以某种方式重用我的连接及其会话锁吗？
2. 就此而言,另一个上下文(例如在另一个线程中)是否可以使用我发出锁定的连接,而原始线程仍然在using块内？ …