避免事务范围的死锁 [英] Avoiding deadlock for transaction scope

查看:207
本文介绍了避免事务范围的死锁的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述




当我们使用 dbcontexts到的事务范围在一个事务范围内的多个方法中实现
,如果在执行之间发生任何异常,那么系统MSDTC将自动处理所有级别的执行回滚。



所以我们希望用我们正在使用的一个范围实现交易  每个方法的独立dbcontext(为每个方法配置
dbcontext)并按顺序执行。这里我们面临的回滚功能不是由msdtc处理的,所以请建议如何 实现独立方法的
回滚功能。




尽快向我们提供一些示例和建议



谢谢,



Sam




Sampath

解决方案

< blockquote>

SQL Server的默认隔离级别为READ COMMITTED。默认情况下,READ COMMITED在读取时使用可能导致锁争用的共享锁。 虽然在每个语句完成时释放锁。



System.Transactions.Transaction的默认隔离级别是Serializable。这意味着如果您使用TransactionScope,则默认选择最严格的隔离级别。可序列化通常会导致严重阻塞和死锁
问题。您应该使用以下内容覆盖TransactionScope的默认构造函数:

 public class TransactionScopeUtils {
public static TransactionScope CreateTransactionScope()
{
TransactionOptions transactionOptions = new TransactionOptions();
transactionOptions.IsolationLevel = IsolationLevel.ReadCommitted;
transactionOptions.Timeout = TransactionManager.MaximumTimeout;
返回新的TransactionScope(TransactionScopeOption.Required,transactionOptions);
}
}

在我的例子中,我选择了ReadCommitted。您还可以查看
ReadUncommitted  允许
许多事务同时在数据存储上运行,并且不会因中断事务而导致数据损坏。


话虽如此,随着Entity Framework 6的推出,Microsoft建议使用新的API方法:Database.BeginTransaction()和Database.UseTransaction()。


https://msdn.microsoft.com/en-us/data/dn456843




Hi,

I am facing a problem like deadlock issue when we are using a transaction scope with dbcontexts to achieve in multiple methods which come under one transaction scope and if any exception occurs in between the execution then the system MSDTC will take care of rollback of all levels of execution automatically.

So we want to achieve transaction with one scope that we are using independent dbcontext for each method(dispose dbcontext for each method) and execute sequentially. Here we are facing rollback functionality which is not handled by msdtc so please suggest how to achieve rollback functionality for independent methods.

please guide us with some examples and suggestions asap

Thanks,

Sam


Sampath

解决方案

The default isolation level of SQL Server is READ COMMITTED. READ COMMITED by default uses shared locks on reads which can potentially cause lock contention. Though locks are released when each statement is completed.

The default isolation level for System.Transactions.Transaction is Serializable. This means that if you use TransactionScope your are by default choosing the most restrictive isolation level. Serializable often introduces severe blocking and deadlocking problems. You should override the TransactionScope's default constructor with something like the following:

public class TransactionScopeUtils {
  public static TransactionScope CreateTransactionScope()
  {
    TransactionOptions transactionOptions = new TransactionOptions();
    transactionOptions.IsolationLevel = IsolationLevel.ReadCommitted;
    transactionOptions.Timeout = TransactionManager.MaximumTimeout;
    return new TransactionScope(TransactionScopeOption.Required, transactionOptions);
  }
}

In my example, I chose ReadCommitted. You can also look into ReadUncommitted allows many transactions to operate on a data store simultaneously and provides no protection against data corruption due to interruptive transactions.

That being said, with the introduction of Entity Framework 6, Microsoft recommends to use new API methods: Database.BeginTransaction() and Database.UseTransaction().

https://msdn.microsoft.com/en-us/data/dn456843


这篇关于避免事务范围的死锁的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆