讀鎖的實體框架類型

什麼是實體框架的默認讀鎖，以及如何實現可重複讀鎖。讀鎖的實體框架類型

在這裏，我想，也許有一個全局設置的地方，這樣一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

讀鎖的實體框架類型

回答

相關問題