读锁的实体框架类型

什么是实体框架的默认读锁，以及如何实现可重复读锁。读锁的实体框架类型

在这里，我想，也许有一个全局设置的地方，这样一readlock默认情况下，再发布一次的SaveChanges中踢后天型重复读。

What is the default transaction isolation level in Entity Framework when I issue “SaveChanges()”? .Says默认隔离级别为快照。我如何改变重复阅读。

来源

2016-01-13 Aflred

您对事务隔离级别的锁定感到困惑。此外，你为什么认为你需要一个锁？这听起来像你在寻找悲观锁定，这对于单用户桌面应用程序以外的任何其他应用程序都是非常糟糕的做法。另一方面，乐观并发可确保正确性和可伸缩性 –

或者您可能试图通过锁实现对象版本控制或至少检出功能。你不能，因为检查一条记录的编辑与锁定无关 - 这是一个更高层次的概念，比锁定更复杂。在行本身或更好使用标志，一个或多个单独的表与谁签出什么 –

基本上，一旦我从一行读取，我想确保在我的当前事务完成之前没有人更改该行。 – Aflred

Msdn告诉默认隔离模式是依赖于数据库的。

它还提供了一个如何处理交易的例子，这就是您需要从隔离模式repeatable read中等待的东西中获益的例子。要小心，他们的例子有一个非常讨厌的缺陷，因为它会吞噬任何异常。

这里是他们的例子的固定版本。 context应该是从DBContext派生的类的一个实例。

 using (var dbContextTransaction = 
      context.Database.BeginTransaction(
       System.Data.IsolationLevel.RepeatableRead)) 
     { 
      try 
      { 
       // Your work here, then 

       context.SaveChanges(); 
       dbContextTransaction.Commit(); 
      } 
      catch 
      { 
       dbContextTransaction.Rollback(); 
       throw; 
      } 
     }

正如Panagiotis Kanavos警告的那样，应该尽可能地避免这种锁定。它减少了可扩展性，增强了死锁的风险，可能会完全阻止其他用户只要事务运行，...

的try catch rollback可以认为是多余的，因为处置正在进行System.Data.SqlClient.SqlTransaction使其回滚（和using会确保它被丢弃）。但是由于具体事务可能是其他类型的事务，因此根据所使用的数据存储库，在出现故障时明确回滚它更安全。

来源

2016-01-13 13:44:22

读锁的实体框架类型

回答

相关问题