我們正在嘗試構建一個大批量訂單記錄系統。 有三個主表： 1.訂單 2.訂單明細 3. OrderShipmentLINQ to SQL和併發問題
的運費表包含n個記錄每個訂單和客戶接受階之前的任何記錄裝運條目可被改變，在這之後是凍結。 （業務需求）
雖然這可能不會發生在真實世界的場景中...... 在我們的負載測試中，我們正在獲取System.Data.Linq.ChangeConflictException異常。 將交易內容包含在交易內容中也無濟於事。 難道我們不能強制LINQ在整個更新操作期間對該行進行鎖定嗎？
有沒有其他辦法可以克服這個問題？
如果您對同一數據的併發更新存在真正的問題，那麼您可以考慮在事務中執行整個操作 - 即獲取數據和提交它。只要您將get/update/commit視爲一個短暫的原子操作（即，您不會在中間暫停用戶輸入），它應該可以。
特別是，使用可序列化的隔離級別，沒有人可以更新您擁有讀鎖的數據（即您所查詢的任何內容）。唯一的問題是，如果不同的查詢以不同的順序讀取數據，這可能導致死鎖情況。 AFAIK，沒有辦法讓LINQ-to-SQL發佈（UPDLOCK）提示，這是一個恥辱。
只要將TransactionScope或SqlTransaction設置爲可序列化隔離（這是TransactionScope的默認值），TransactionScope或SqlTransaction都可以執行此操作。
嗨， 感謝您的回覆... 我曾嘗試將其封裝在一個事務下，我只是得到一個不同的例外......該操作是死鎖的受害者。 親切的問候， Ashish Sharma – 2008-10-10 11:40:37
我想知道這是鎖定升級的死鎖還是不同的順序死鎖？如果前者，一個選項（儘管你失去了很多LINQ的好處）可能是用SP查詢數據 - 那麼你可以包含UPDLOCK提示，防止鎖升級問題。 – 2008-10-10 12:15:55
（仍然通過LINQ，我的意思是 - 即告訴設計者這個SP返回這個表） – 2008-10-10 12:16:36
你可能想看看Entity Framework它執行一切事務。以下是兩個播客，這些播客對實體框架也很有趣。
對於這種情況，即在多於一個用戶可能想要更改相同的記錄/客戶/訂單/不管它是更好地建設「鎖定」到應用程序邏輯而不是使用數據庫鎖。
使用數據庫鎖來解決數據的邏輯鎖定會給你帶來一堆新問題。一個更好的解決方案是有列和/或表格，在這些列和/或表格中你可以指示訂單/客戶/等正在被[用戶]編輯，直到它被鎖定爲止等等。查詢該表格（或列）以檢查客戶/ order/thing可以在允許其他用戶進行編輯之前進行編輯。
參見： http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3984968&SiteID=1
你是如何處理LINQ併發？ – flesh 2008-11-19 16:29:55