c# - Entity Framework 死锁

Question

我在处理某个特定实现时遇到了问题。
我有一个基本的方法来创建一个新的上下文，查询一个表并从表中获取“LastNumberUsed”，在最终增加和写回之前对这个数字执行一些基本检查——所有这些都在一个事务中。

我已经编写了一个基本的测试应用程序，它使用 Parallel.For 来执行这个方法 5 次。
使用 Isolation.Serialization 我发现在运行此代码时出现了很多死锁错误。
我已经阅读了一些关于这个主题的内容，并尝试将隔离级别更改为快照。我不再遇到死锁，而是发现我遇到了隔离更新冲突错误。

我真的不知道该怎么办。每个事务大约需要 0.009 秒才能完成，所以我一直在考虑将代码包装在 try..catch 中，检查死锁错误并再次运行，但这感觉像是一个困惑的解决方案。

有没有人对如何处理这个问题有任何想法(或最好的经验)？

我创建了一个控制台应用程序来演示这一点。
在程序 main 中，我运行以下代码:

    Parallel.For(0, totalRequests, 
          x => TestContract(x, contractId, incrementBy, maxRetries));

方法 TestContract 看起来像这样:

//Define the context
using (var context = new Entities())
{
    //Define a new transaction
    var options = new TransactionOptions {IsolationLevel = IsolationLevel.Serializable};
    using (var scope = new TransactionScope(TransactionScopeOption.Required, options))
    {
        //Get the contract details
        var contract = (
            from c in context.ContractRanges
            where c.ContractId == contractId
            select c).FirstOrDefault();

        //Simulate activity
        Threading.Thread.sleep(50);

        //Increment the contract number
        contract.Number++;

        //Save the changes made to the context
        context.SaveChanges();

        //Complete the scope
        scope.Complete();
    }
}
    }

Answer 1

暂时将隔离级别放在一边，让我们专注于您的代码正在做什么:

您正在并行运行 5 个调用 TestContract 的任务。路过一样contractId对于他们所有人，对吧？

在 TestContract您获取 contract由其 id ，用它做一些工作，然后增加 Number契约(Contract)的属性(property)。

所有这一切都在交易边界内。

为什么会出现死锁？

为了理解为什么会陷入僵局，了解 Serializable 是什么很重要。隔离级别是指。

documentation of SQL Server Isolation Levels以下是关于 Serializable 的内容(强调我的):

• Statements cannot read data that has been modified but not yet committed by other transactions.
• No other transactions can modify data that has been read by the current transaction until the current transaction completes.
• Other transactions cannot insert new rows with key values that would fall in the range of keys read by any statements in the current transaction until the current transaction completes.

Range locks are placed in the range of key values that match the search conditions of each statement executed in a transaction. This blocks other transactions from updating or inserting any rows that would qualify for any of the statements executed by the current transaction. This means that if any of the statements in a transaction are executed a second time, they will read the same set of rows. The range locks are held until the transaction completes. This is the most restrictive of the isolation levels because it locks entire ranges of keys and holds the locks until the transaction completes. Because concurrency is lower, use this option only when necessary. This option has the same effect as setting HOLDLOCK on all tables in all SELECT statements in a transaction.

回到你的代码，为了这个例子，假设你只有两个并行运行的任务， TaskA和 TaskB与 contractId=123 , 全部在与 Serializable 的交易下隔离级别。

让我们试着描述一下这个执行过程中代码发生了什么:

任务 A 开始

TaskB 开始

任务A 创建一个Transaction 1234具有可序列化隔离级别

TaskB 创建 Transaction 5678具有可序列化隔离级别

TaskA 生成 SELECT * FROM ContractRanges WHERE ContractId = 123 .
这一点。 SQL Server 在 ContractRanges 中放置了一个锁表，在 ContractId = 123 所在的行中以防止其他事务改变该数据。

TaskB 使相同 SELECT声明并放了一个 lock在 ContractId = 123排的ContractRanges table 。

因此，此时，我们在同一行上有两个锁，一个用于您创建的每个事务。

TaskA 然后增加 Number契约(Contract)

TaskB 增加 Number契约(Contract)属性(property)

TaskA 调用，SaveChanges反过来，它会尝试提交事务。

因此，当您尝试提交事务时 1234 ，我们正在尝试修改 Number具有事务创建的锁的行中的值 5678所以，SQL Servers 开始等待 lock被释放以便按照您的要求提交事务。

TaskB ，然后，也调用 SaveChanges ，就像发生在 TaskA 上一样，它试图增加 Number契约(Contract)123 .在这种情况下，它会找到一个 lock在事务创建的那一行 1234来自 TaskA .

现在我们有交易 1234来自 TaskA等待来自事务的锁 5678待发布 和 交易 5678等待来自事务的锁 1234即将面世。这意味着我们处于死锁状态，因为两个事务都无法完成，因为它们相互阻塞。

当 SQL Server 识别出它处于死锁情况时，它会选择事务之一作为 victim ，杀死它并允许另一个继续。

回到隔离级别，如果你真的需要，我没有足够的关于你想要做什么的细节让我有意见 Serializable ，但很有可能您不需要它。 Serializable是最安全和最严格的隔离级别，它通过牺牲并发性来实现，就像我们看到的那样。

如果您真的需要 Serializable保证您真的不应该尝试更新 Number同时签同一份契约(Contract)。
Snapshot Isolation选择

你说:

I have read a bit on this subject and tried changing the isolation level to snapshot. I no longer get deadlocks but instead find I get isolation update conflict errors.

如果您选择使用快照隔离，这正是您想要的行为。那是因为 Snapshot使用乐观并发模型。

以下是它在同一个 MSDN 文档中的定义(再次强调我的):

Specifies that data read by any statement in a transaction will be the transactionally consistent version of the data that existed at the start of the transaction. The transaction can only recognize data modifications that were committed before the start of the transaction. Data modifications made by other transactions after the start of the current transaction are not visible to statements executing in the current transaction. The effect is as if the statements in a transaction get a snapshot of the committed data as it existed at the start of the transaction.

Except when a database is being recovered, SNAPSHOT transactions do not request locks when reading data. SNAPSHOT transactions reading data do not block other transactions from writing data. Transactions writing data do not block SNAPSHOT transactions from reading data.

During the roll-back phase of a database recovery, SNAPSHOT transactions will request a lock if an attempt is made to read data that is locked by another transaction that is being rolled back. The SNAPSHOT transaction is blocked until that transaction has been rolled back. The lock is released immediately after it has been granted.

The ALLOW_SNAPSHOT_ISOLATION database option must be set to ON before you can start a transaction that uses the SNAPSHOT isolation level. If a transaction using the SNAPSHOT isolation level accesses data in multiple databases, ALLOW_SNAPSHOT_ISOLATION must be set to ON in each database.

A transaction cannot be set to SNAPSHOT isolation level that started with another isolation level; doing so will cause the transaction to abort. If a transaction starts in the SNAPSHOT isolation level, you can change it to another isolation level and then back to SNAPSHOT. A transaction starts the first time it accesses data.

A transaction running under SNAPSHOT isolation level can view changes made by that transaction. For example, if the transaction performs an UPDATE on a table and then issues a SELECT statement against the same table, the modified data will be included in the result set.

让我们尝试描述代码在快照隔离下执行时发生了什么:

假设 Number 的初始值是 2契约(Contract)123

任务 A 开始

TaskB 开始

任务A 创建一个Transaction 1234具有快照隔离级别

TaskB 创建 Transaction 5678具有快照隔离级别

在两个快照中， Number = 2契约(Contract) 123 .

TaskA 生成 SELECT * FROM ContractRanges WHERE ContractId = 123 .因为我们在 Snapshot 下运行隔离，没有locks .

TaskB 使相同 SELECT声明，也做 不是 放任何 locks .

TaskA 然后增加 Number契约(Contract)到3

TaskB 增加 Number契约(Contract)属性(property)到3

TaskA 调用，SaveChanges反过来，这会导致 SQL Server 将创建事务时创建的快照与数据库的当前状态以及在此事务下所做的未提交更改进行比较。由于没有发现任何冲突，它提交了事务，现在 Number值为 3在数据库中。

TaskB ，然后，也调用 SaveChanges ，并尝试提交其事务。当 SQL Server 将事务快照值与数据库中当前的值进行比较时，它会发现冲突。在快照中，Number有一个值 2现在它的值为 3 .然后，它抛出 Update Exception .

同样，没有死锁，但是 TaskB这次失败了，因为 TaskA变异了也在 TaskB 中使用的数据.

如何解决这个问题

现在我们已经介绍了在 Serializable 下运行代码时发生的情况。和 Snapshot隔离级别，您可以对 fix 做些什么它。

嗯，你应该考虑的第一件事是，如果你同时变异相同的 Contract 真的有意义吗？记录。这是我在您的代码中看到的第一个大气味，我会先尝试理解这一点。您可能需要与您的企业讨论这个问题，以了解他们是否真的需要契约(Contract)中的这种并发性。

假设你真的需要同时发生，正如我们所看到的，你不能真正使用 Serializable因为这会导致 deadlocks就像你看到的那样。所以，我们只剩下 Snapshot隔离。

现在，当你 catch OptmisticConcurrencyException这真的由你来处理取决于你和你的企业来决定。

例如，处理它的一种方法是通过向用户显示错误消息通知他们试图更改的数据已被修改并询问他们是否要刷新屏幕来简单地委托(delegate)给用户来决定要做什么获取最新版本的数据，并在需要时再次尝试执行相同的操作。

如果不是这种情况，并且您可以重试，另一种选择是在您的代码中设置一个重试逻辑，当 OptmitisticConcurrencyException 出现时重试执行操作。被抛出。这是基于这样的假设:在第二次时，不会有并发事务改变相同的数据并且操作现在将成功。