5

将 EF 用于MSSQL 2008. 所以我把ReadUncommitted事务隔离级别，希望能解决，像这样，

前 

using (MyEntities db = new MyEntities())
{
    // large dataset
    var data = from _Contact in db.Contact where _Contact.MemberId == 13 select _Contact;
    for (var item in data)
          item.Flag = 0;

    // Probably db lock      
    db.SaveChanges(); 
}

后

using (var scope =
    new TransactionScope(TransactionScopeOption.RequiresNew,
    new TransactionOptions() { IsolationLevel = IsolationLevel.ReadUncommitted }))
{
    using (MyEntities db = new MyEntities())
    {
        // large dataset but with NOLOCK
        var data = from _Contact in db.Contact where _Contact.MemberId == 13 select _Contact;
        for (var item in data)
              item.Flag = 0;

        // Try avoid db lock      
        db.SaveChanges();
    }
}

我们SQL profiler用来追踪。但是，按顺序获取这些脚本，（期望第一个脚本未提交读取。）

审核登录

set transaction isolation level read committed

SP:StmtStarting 

SELECT 
 [Extent1].[ContactId] AS [ContactId], 
 [Extent1].[MemberId] AS [MemberId], 
FROM [dbo].[Contact] AS [Extent1]
WHERE [Extent1].[MemberId] = @p__linq__0

审核登录

set transaction isolation level read uncommitted

尽管我可以重新发送此请求并使其顺序正确（将显示read-uncommitted以下请求，相同的SPID），但我想知道为什么它在 read-committed 命令之后发送 read-uncommitted 命令以及如何使用 EF 和TransactionScope进行修复？谢谢。

4

3 回答 3

5

我认为这是依赖审计登录事件引起的红鲱鱼。这没有显示客户端告诉服务器“设置事务隔离级别读取未提交”的那一刻。当该连接从池中取出并重用时，它会向您显示稍后的隔离级别。

我通过添加Pooling=false到我的连接字符串来验证这一点。然后，审核登录始终显示已提交的事务隔离级别读取。

到目前为止，我在 SQL Profiler 中没有发现 EF 设置事务级别的时刻，也没有任何明确begin tran的 .

我可以通过读取和记录级别来确认它被设置在某个地方：

    const string selectIsolationLevel = @"SELECT CASE transaction_isolation_level  WHEN 0 THEN 'Unspecified'  WHEN 1 THEN 'ReadUncommitted'  WHEN 2 THEN 'ReadCommitted'  WHEN 3 THEN 'Repeatable'  WHEN 4 THEN 'Serializable'  WHEN 5 THEN 'Snapshot' END AS TRANSACTION_ISOLATION_LEVEL  FROM sys.dm_exec_sessions  where session_id = @@SPID";

    static void ReadUncommitted()
    {
        using (var scope =
            new TransactionScope(TransactionScopeOption.RequiresNew,
            new TransactionOptions{ IsolationLevel = IsolationLevel.ReadUncommitted }))
        using (myEntities db = new myEntities())
        {
            Console.WriteLine("Read is about to be performed with isolation level {0}", 
                db.Database.SqlQuery(typeof(string), selectIsolationLevel).Cast<string>().First()
                );
            var data = from _Contact in db.Contact where _Contact.MemberId == 13 select _Contact; // large results but with nolock

            foreach (var item in data)
                item.Flag = 0;

            //Using Nuget package https://www.nuget.org/packages/Serilog.Sinks.Literate
            //logger = new Serilog.LoggerConfiguration().WriteTo.LiterateConsole().CreateLogger();
            //logger.Information("{@scope}", scope);
            //logger.Information("{@scopeCurrentTransaction}", Transaction.Current);
            //logger.Information("{@dbCurrentTransaction}", db.Database.CurrentTransaction);

            //db.Database.ExecuteSqlCommand("-- about to save");
            db.SaveChanges(); // Try avoid db lock
            //db.Database.ExecuteSqlCommand("-- finished save");
            //scope.Complete();
        }
    }

（我说“有点”是因为每个语句都在自己的会话中运行）

也许这是一个很长的说法，是的，即使您无法通过 Profiler 证明，EF 事务也可以正常工作。

于 2017-01-21T04:47:33.183 回答
3

根据 ADO.NET 文档Snapshot Isolation in SQL Server中的以下注释，只要底层连接被池化，Isolation Level 就不会绑定到 Transaction Scope：

如果连接是池化的，则重置其隔离级别不会重置服务器上的隔离级别。因此，使用相同池化内部连接的后续连接开始时将其隔离级别设置为池化连接的隔离级别。关闭连接池的另一种方法是为每个连接显式设置隔离级别。

因此，我得出结论，在 SQL Server 2012 之前，将隔离设置为任何其他级别，而不是ReadCommitted在创建有问题的 SqlConnection 时打开连接池或在每个连接中显式设置隔离级别以避免意外行为，包括死锁。或者，可以通过调用ClearPool Method来清除连接池，但由于此方法既不绑定到事务范围也不绑定到底层连接，我认为当多个连接同时针对同一个池化内部连接运行时，它是不合适的。

参考SQL 论坛中的SQL Server 2014 重置隔离级别帖子和我自己的测试，当使用 SQL Server 2014 和具有 TDS 7.3 或更高版本的客户端驱动程序时，此类解决方法已过时。

于 2017-01-23T13:31:24.437 回答
-1

我认为更好的解决方案是通过生成直接查询（而不是逐个选择和更新实体）来执行更新。为了使用对象而不是查询，您可以使用EntityFramework.Extended：

db.Contact.Update(C => c.MemberId == 13, c => new Contact { Flag = 0 });

这应该会生成UPDATE Contact SET Flag = 0 WHERE MemberId = 13比您当前的解决方案更快的东西。

如果我没记错的话，这应该会生成自己的交易。如果这必须在与其他查询的事务中执行，`TransactionScope 仍然可以使用（您将有两个事务）。

此外，隔离级别可以保持不变（ReadCommitted）。

[编辑]

Chris's 分析准确地显示了发生的情况。为了使其更加相关，以下代码显示了内部和外部的区别TransactionScope：

using (var db = new myEntities())
{
    // this shows ReadCommitted
    Console.WriteLine($"Isolation level outside TransactionScope = {db.Database.SqlQuery(typeof(string), selectIsolationLevel).Cast<string>().First()}");
}

using (var scope =
    new TransactionScope(TransactionScopeOption.RequiresNew,
    new TransactionOptions() { IsolationLevel = IsolationLevel.ReadUncommitted }))
{
    // this show ReadUncommitted
    Console.WriteLine($"Isolation level inside TransactionScope = {db.Database.SqlQuery(typeof(string), selectIsolationLevel).Cast<string>().First()}");

    using (myEntities db = new myEntities ())
    {
        var data = from _Contact in db.Contact where _Contact.MemberId == 13 select _Contact; // large results but with nolock

        for (var item I data)
              item.Flag = 0;
        db.SaveChanges(); // Try avoid db lock
    }

    // this should be added to actually Commit the transaction. Otherwise it will be rolled back
    scope.Complete();
}

回到实际问题（出现死锁），如果我们查看 Profiler 在整个过程中输出的内容，我们会看到类似这样的内容（已删除GOs）：

BEGIN TRANSACTION 
SELECT <all columns> FROM Contact 
exec sp_reset_connection

exec sp_executesql N'UPDATE Contact
    SET [Flag] = @0
    WHERE ([Contact] = @1)
    ',N'@0 nvarchar(1000),@1 int',@0=N'1',@1=1

-- lots and lots of other UPDATEs like above

-- or ROLLBACK if scope.Complete(); is missed
COMMIT

这有两个缺点：

  1. 许多往返- 对数据库发出许多查询，这给数据库引擎带来了更大的压力，并且客户端花费的时间也更长

  2. 长事务——应避免长事务，以尽量减少死锁

因此，建议的解决方案在您的特定情况下应该会更好（简单更新）。

在更复杂的情况下，可能需要更改隔离级别。

我认为，如果处理大量数据（选择数百万，做某事，更新等），存储过程可能是解决方案，因为一切都在服务器端执行。

于 2017-01-20T13:34:15.733 回答