我想使用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