LINQ to SQL 结合未提交读和已提交读
我想使用 LINQ to SQL 作为应用程序的数据层。乐观并发似乎会起作用，但我想过于乐观，不去理会任何锁定（例如 ReadUncommissed 又名 WITH (NOLOCK)），直到我得到到 SubmitChanges()，此时我认为使用 ReadComfilled 就可以了。
这听起来很疯狂吗？是否最好使用两个分离的 TransactionScope 对象（一个用于使用 ReadUncommissed 进行读取，第二个用于使用 ReadCommited 提交更改），或者是有没有更好的方法可以在提交更改之前立即提高隔离级别？
I'd like to use LINQ to SQL as the data layer for an application. Optimistic concurrency seems like it would work, but I'd like to be over-optimistic and not bother with any locking (e.g. ReadUncommitted a.k.a. WITH (NOLOCK)) until I get to SubmitChanges(), at which point I think it's OK to use ReadCommitted.
Does this sound like madness? Is it better to use two disjunct TransactionScope objects (one for reading with ReadUncommitted, followed by a second for submitting changes with ReadCommitted), or is there some nicer way I can raise the isolation level immediately before submitting changes?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
ReadCommited或ReadUncommissed在SubmitChanges()上并不重要，因为它是写入，而不是读取。无论隔离级别是什么，更新始终会获取锁并尊重现有锁。必须如此，这就是锁的主要目的。当然，通过更新未提交的数据，您将面临记录甚至不存在、无法更新的风险，但这是您在决定乐观时接受的风险。
ReadCommittedorReadUncommitteddoes not matter on aSubmitChanges()because it is a write, not a read. No matter what the isolation level, an update always acquires a lock and respects existing locks. It has to, that is the main purpose of locks.Of course, by updating uncommitted data you run the risk that the record does not even still exist to be updated, but that was the risk you accepted when deciding to be optimistic.