我想使用LINQ to SQL作爲應用程序的數據層。樂觀的併發看起來可能會奏效，但我希望過於樂觀，並且不打擾任何鎖定（例如ReadUncommitted也就是WITH (NOLOCK)），直到我到達SubmitChanges()，此時我認爲可以使用ReadCommitted。LINQ to SQL結合讀取未提交和讀取提交
聽起來這是瘋了嗎？使用兩個分離的TransactionScope對象（一個用ReadUncommitted讀取，其次是用於提交ReadCommitted的更改），還是有更好的方法可以在提交更改之前立即提高隔離級別？
ReadCommitted或ReadUncommitted與SubmitChanges()無關，因爲它是寫入而不是讀取。無論隔離級別如何，更新總是會獲得一個鎖並且尊重現有的鎖。它必須這是鎖的主要目的。
當然，通過更新未提交的數據，您可能會冒這個記錄甚至不存在需要更新的風險，但這是您在決定保持樂觀時接受的風險。
我不確定這是真的。 LINQ to SQL需要檢查ROWVERSION字段，以在提交更改之前檢查是否存在樂觀併發衝突。我擔心的是它可能會繼續在併發檢查中使用我的事務的ReadUncommitted隔離級別。 – Jono
事務隔離級別與併發檢查無關。 – DevDelivery
我猜你認爲併發檢查首先進行一次讀取以檢查併發性，如果沒有問題，則執行更新。但是，併發檢查內置在update語句本身中，正如我在答案中指出的，Update始終尊重鎖。 – DevDelivery
如果您正在閱讀爲什麼要在交易範圍內完成此操作。事務選擇是沒有意義的。 –
這是不正確的。通過讀取未提交的數據，可能會稍後回滾數據，因此用戶正在更新重影。通過不對數據保持讀鎖定，其他用戶可以更新此更新將被盲目覆蓋的數據。 – DevDelivery
我不同意。使用readuncommitted選項的事務讀取將允許我立即（更快）地訪問可能被其他進程鎖定的行。 – Jono