.net - Entity Framework 和事务范围在处理事务范围后不会恢复隔离级别

Question

我正在努力处理事务范围和 Entity Framework 。

最初，我们希望应用程序中的所有连接在读取数据时都使用快照隔离级别，但在某些情况下，我们希望使用已提交读或未提交读隔离级别来读取数据，为此我们将使用事务范围来临时更改隔离级别用于查询(正如这里和不同博客中的几篇文章所指出的那样)。

但是，问题是当事务范围被释放时，隔离仍然存在于连接上，这会导致相当多的问题。

我尝试了所有类型的变体，但结果相同；隔离级别保留在事务范围之外。

有没有人可以为我解释这种行为或可以解释我做错了什么？

我通过将事务范围封装在为我恢复隔离级别的一次性类中找到了解决该问题的方法，但我希望对这种行为有一个很好的解释，我认为这种行为不仅影响我的代码，而且其他人也是。

这是一个说明问题的示例代码:

using (var context = new MyContext())
{
    context.Database.Connection.Open();

    //Sets the connection to default read snapshot
    using (var command = context.Database.Connection.CreateCommand())
    {
        command.CommandText = "SET TRANSACTION ISOLATION LEVEL SNAPSHOT";
        command.ExecuteNonQuery();
    }

    //Executes a DBCC USEROPTIONS to print the current connection information and this shows snapshot
    PrintDBCCoptions(context.Database.Connection);

    //Executes a query
    var result = context.MatchTypes.ToArray();

    //Executes a DBCC USEROPTIONS to print the current connection information and this still shows snapshot
    PrintDBCCoptions(context.Database.Connection);

    using (var scope = new TransactionScope(TransactionScopeOption.Required,
        new TransactionOptions()
        {
            IsolationLevel = IsolationLevel.ReadCommitted //Also tried ReadUncommitted with the same result
        }))
    {
        //Executes a DBCC USEROPTIONS to print the current connection information and this still shows snapshot
        //(This is ok, since the actual new query with the transactionscope isn't executed yet)
        PrintDBCCoptions(context.Database.Connection);
        result = context.MatchTypes.ToArray();
        //Executes a DBCC USEROPTIONS to print the current connection information and this has now changed to read committed as expected                    
        PrintDBCCoptions(context.Database.Connection);
        scope.Complete(); //tested both with and without
    }

    //Executes a DBCC USEROPTIONS to print the current connection information and this is still read committed
    //(I can find this ok too, since no command has been executed outside the transaction scope)
    PrintDBCCoptions(context.Database.Connection);
    result = context.MatchTypes.ToArray();

    //Executes a DBCC USEROPTIONS to print the current connection information and this is still read committed
    //THIS ONE is the one I don't expect! I expected that the islation level of my connection should revert here
    PrintDBCCoptions(context.Database.Connection);
}

Answer 1

好吧，经过今天的一些挖掘，我发现了一些关于这个的东西，我将分享发现，以供其他人了解并获得意见和建议。

我的问题发生的原因有多种，具体取决于环境。

数据库服务器版本:

首先，操作的结果取决于您运行的 SQL Server 版本(在 SQL Server 2012 和 SQL Server 2014 上测试)。

SQL Server 2012

在 SQL Server 2012 上，最后设置的隔离级别将跟随后续操作的连接，即使它被释放回连接池并从其他线程/操作中检索回来。在实践中;这意味着，如果您在某个线程/操作中将隔离级别设置为使用事务未提交的读取，则连接将保留这一点，直到另一个事务范围将其设置为另一个隔离级别(或通过在联系)。不好，您可能会在不知情的情况下突然获得脏读。

例如:

Console.WriteLine(context.MatchTypes.Where(mt => mt.Id == 2).Select(mt => mt.LastUpdated).First());

using (var scope = new TransactionScope(TransactionScopeOption.Required, 
                                        new TransactionOptions 
                                        { 
                                            IsolationLevel = IsolationLevel.ReadUncommitted 
                                        }))
{
    Console.WriteLine(context.MatchTypes.Where(mt => mt.Id == 2)
                                        .Select(mt => mt.LastUpdated).First());
    scope.Complete(); //tested both with and without
}

Console.WriteLine(context.MatchTypes.Where(mt => mt.Id == 2).Select(mt => mt.LastUpdated).First());

在这个例子中，第一个 EF 命令将使用数据库默认值运行，事务范围内的一个将使用 ReadUncommitted 运行，第三个也将使用 ReadUncommitted 运行。

SQL Server 2014

另一方面，在 SQL Server 2014 上，每次从连接池中获取连接时， sp_reset_connection 过程(无论如何似乎都是这个)会将数据库上的隔离级别设置回默认值，即使重新获取连接来自同一交易范围内。在实践中;这意味着如果您有一个事务范围，在其中执行两个后续命令，则只有第一个将获得事务范围的隔离级别。也不好；您将获得(基于数据库上的默认隔离级别)获得锁定或快照读数。

例如:

Console.WriteLine(context.MatchTypes.Where(mt => mt.Id == 2).Select(mt => mt.LastUpdated).First());

using (var scope = new TransactionScope(TransactionScopeOption.Required, 
                                        new TransactionOptions 
                                        { 
                                            IsolationLevel = IsolationLevel.ReadUncommitted 
                                        }))
{
    Console.WriteLine(context.MatchTypes.Where(mt => mt.Id == 2)
                             .Select(mt => mt.LastUpdated).First());
    Console.WriteLine(context.MatchTypes.Where(mt => mt.Id == 2)
                             .Select(mt => mt.LastUpdated).First());
    scope.Complete(); 
}

在此示例中，第一个 EF 命令将使用数据库默认值运行，事务中的第一个命令将使用 ReadUncommitted 运行，但范围内的第二个命令将突然再次作为数据库默认值运行。

手动打开连接问题:

在手动打开连接的不同 SQL Server 版本上还会发生其他问题，但是，我们绝对不需要这样做，所以我现在不打算详细讨论这个问题。

使用 Database.BeginTransaction:

出于某种原因，Entity Framework 的 Database.BeginTransaction 逻辑似乎在两个数据库中都可以工作，但在我们的代码中，我们针对两个不同的数据库工作，然后我们需要事务范围。

结论:

在此之后，我发现这种隔离级别与 SQL Server 中事务范围的处理非常有问题，在我看来，使用它并不安全，并且可能会在我所见的任何应用程序中导致严重问题。使用这个要非常小心。

但事实仍然存在，我们需要在我们的代码中使用它。最近处理了 MS 乏味的支持，结果不是很好，我会首先找到适合我们的解决方法。然后，我将使用 Connect 报告我的发现，并希望 Microsoft 在事务范围处理和连接方面采取一些措施。

解决方案:

解决方案(就我而言)是这样的。

以下是此解决方案的要求:
1.数据库 必须由于针对同一数据库运行的其他应用程序需要在隔离级别上进行 READ COMMITTED，我们不能在数据库上使用 READ COMMITTED SNAPSHOT 默认值
2.我们的申请 必须有一个默认的 SNAPSHOT 隔离级别
- 这是通过使用 SET TRANSACTION ISOLATIONLEVEL SNAPSHOT 解决的
3.如果有事务范围，我们需要为此尊重隔离级别

因此，基于这些标准，解决方案将是这样的:

在上下文构造函数中，我注册到 StateChange 事件，当状态更改为 Open 并且没有事件事务时，我依次使用经典的 ADO.NET 将隔离级别默认为快照。如果使用事务范围，我们需要根据这里的设置运行 SET TRANSACTION ISOLATIONLEVEL 来遵守这个设置(为了限制我们自己的代码，我们将只允许 ReadCommitted、ReadUncommitted 和 Snapshot 的 IsolationLevel)。至于由 Database.BeginTransaction 在上下文中创建的事务，这似乎是值得尊重的，因此我们不对这些类型的事务执行任何特殊操作。

这是上下文中的代码:

public MyContext()
{
    Database.Connection.StateChange += OnStateChange;
}

protected override void Dispose(bool disposing)
{
    if(!_disposed)
    {
        Database.Connection.StateChange -= OnStateChange;
    }

    base.Dispose(disposing);
}

private void OnStateChange(object sender, StateChangeEventArgs args)
{
    if (args.CurrentState == ConnectionState.Open && args.OriginalState != ConnectionState.Open)
    {
        using (var command = Database.Connection.CreateCommand())
        {
            if (Transaction.Current == null)
            {
                command.CommandText = "SET TRANSACTION ISOLATION LEVEL SNAPSHOT";
            }
            else
            {
                switch (Transaction.Current.IsolationLevel)
                {
                    case IsolationLevel.ReadCommitted:
                        command.CommandText = "SET TRANSACTION ISOLATION LEVEL READ COMMITTED";
                        break;
                    case IsolationLevel.ReadUncommitted:
                        command.CommandText = "SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED";
                        break;
                    case IsolationLevel.Snapshot:
                        command.CommandText = "SET TRANSACTION ISOLATION LEVEL SNAPSHOT";
                        break;
                    default:
                        throw new ArgumentOutOfRangeException();
                }
            }

            command.ExecuteNonQuery();
        }
    }
}

我已经在 SQL Server 2012 和 2014 中测试了这段代码，它似乎有效。它不是最好的代码，它有它的局限性(例如，它会为每个 EF 执行始终对数据库执行 SET TRANSACTION ISOLATIONLEVEL，从而增加额外的网络流量。)