LINQ to SQL 结合未提交读和已提交读答案

【问题标题】：LINQ to SQL combining read uncommitted and read committedLINQ to SQL 结合未提交读和已提交读
【发布时间】：2011-09-08 11:08:22
【问题描述】：

我想使用 LINQ to SQL 作为应用程序的数据层。乐观并发似乎可以工作，但我想过于乐观并且不打扰任何锁定（例如ReadUncommitted 又名WITH (NOLOCK)），直到我到达SubmitChanges()，此时我认为可以使用ReadCommitted。

这听起来很疯狂吗？最好使用两个分离的TransactionScope 对象（一个用于读取ReadUncommitted，然后第二个用于使用ReadCommitted 提交更改），还是有更好的方法可以在提交更改之前立即提高隔离级别？

【问题讨论】：

如果您正在阅读为什么要在事务范围内执行此操作。事务选择是没有意义的。
这不是真的。通过读取未提交的数据，有可能数据后来被回滚，因此用户正在更新幽灵。并且通过不对数据保持读锁定，其他用户可能会更新此更新将盲目覆盖的数据。
我不同意。带有 readuncommitted 选项的事务性读取将允许我立即（更快）访问可能被其他进程锁定的行。
@DevDelivery - 我不知道（使用 LINQ to SQL 的内置乐观并发检查）进程可能会盲目地覆盖另一个数据的情况。我将其视为第一次更新获胜的场景，后来的更新尝试因 ChangeConflictExceptions 而失败。如果一个进程正在更新一个ghost，它仍然需要在保存更新之前释放ghost的锁......
@Jono - 我指出事务选择具有价值。是的，并发检查可以避免这种情况，但您必须全部设置 - 指定要检查并发的列然后捕获任何异常。

【解决方案1】：

ReadCommitted 或 ReadUncommitted 在 SubmitChanges() 上无关紧要，因为它是写入而不是读取。无论隔离级别如何，更新始终获取锁并尊重现有锁。它必须，这就是锁的主要用途。

当然，通过更新未提交的数据，您冒着记录甚至不存在要更新的风险，但这是您在决定乐观时接受的风险。

【讨论】：

我不确定这是不是真的。 LINQ to SQL 需要在提交更改之前检查 ROWVERSION 字段以检查乐观并发冲突。我担心它可能会在并发检查中继续使用我的事务的 ReadUncommitted 隔离级别。
事务隔离级别与并发检查无关。
我猜您认为并发检查首先会读取以检查并发性，如果可以，则进行更新。但是，并发检查内置在更新语句本身中，正如我在答案中指出的那样，更新始终尊重锁。
是的，我认为这就是发生的事情。我想我可以查看日志输出以验证它只是一个单独的更新，它 - 你指出是正确的 - 总是取出锁。如果是这种情况，那么我可以使用单个 TransactionScope 来构建上下文中的实体...
谢谢，看来您是对的。 UPDATE 语句本身就是并发检查：它使用 WHERE 子句中的 ROWVERSION 字段。