c# - 事务死锁和 DBContext

Question

您好，我正在使用 Entity Framework 4.1 代码优先方法。我有类 MyContainer 继承 DBContext 。

我有一个有 7 个步骤的流程，每个步骤访问许多存储库方法(大约 60 个)。这个流程自动或手动执行取决于业务逻辑和用户需求。现在对于自动进程的性能观点，我创建了上下文，即 MyContainer 的对象一次并将其传递给所有方法并在进程结束时处理它并且它的工作正常并提高了性能。但是当这个手动执行流程，执行相同的方法，并在方法本身中创建和处置容器。例如下面，但这只是粗略的代码。

public bool UpdateProcess(Process process, MyContainer container = null)
    {
        bool disposeContainer = false;
        if (container == null)
        {
            container = new MyContainer();
            disposeContainer = true;
        }
        var result = SaveProcess(container, process);
        container.SaveChanges();
        if (disposeContainer)
            container.Dispose();
        return result;
    }

对于自动流程，交易在流程开始时创建并在流程结束时结束，对于手动交易，在根据用户在 ui 上的操作调用的方法中的 bll 处创建。现在假设我的自动进程正在运行，同时用户在 ui 上做了一些操作，调用 UpdateProcess() 方法时出现异常 “事务(进程 ID 65) 在与另一个进程锁定资源时被死锁并已被选择”结合手动和自动过程，我在 container.SaveChanges() 上得到它。

任何帮助将不胜感激。

如果我在这个存储库方法中创建一个事务范围，比如

public bool UpdateProcess(Process process, MyContainer container = null)
 {         bool disposeContainer = false;        
           if (container == null)  
           {             
                  container = new MyContainer();         
                  disposeContainer = true;         
            }
       using(var trans=new TransactionScop(TransactionScopeOption.RequiresNew))        
       { 
          var result = SaveProcess(container, process);
          container.SaveChanges();
          trans.Complete();
       }        
          if (disposeContainer)           
          container.Dispose();        
          return result;   
 } 

它工作正常。但是我不想在存储库中创建交易，因为交易已经在 bll 中完成。

任何帮助都会得到帮助。

Answer 1

您遇到的问题(sql 死锁)对于大多数重要的客户端-数据库系统来说很常见，并且可能很难解决。

设计可能发生死锁的代码的主要规则是假设它们会发生，并设计应用程序以适本地处理它们。这通常通过重新提交交易来处理。正如微软记录的那样 here

Although deadlocks can be minimized, they cannot be completely avoided. That is why the front-end application should be designed to handle deadlocks.

为了尽量减少您看到的任何死锁，我采用的正常方法如下:

1. 运行分析器并启用死锁图以捕获所有死锁
2. 将所有死锁导出到文本并调查它们发生的原因
3. 检查是否可以通过使用表提示和/或降低事务隔离级别来最小化这些问题
4. 看看是否可以通过其他方式将它们最小化，例如改变操作顺序
5. 最后，在所有这些都完成之后，确保您在与数据库通信并重新提交事务/查询等时随时陷入死锁。