使用企业库时的事务范围和死锁

发布于 2024-11-01 02:59:35 字数 130 浏览 1 评论 0原文

我们正在使用企业库进行数据访问。

我们的方法之一是对同一个表进行删除,然后插入。这造成了僵局。

如果我们将它们放在事务范围内,则不再发生死锁。

直觉上,感觉应该是相反的。谁能解释为什么它会这样工作?

We are using Enterprise Library for data access.

One of our methods has a delete and then an insert, against the same table. This gives a deadlock.

If we put these inside a transaction scope the deadlock no longer occurs.

Intuitively, it feels like it should be the opposite way around. Can anyone explain why it works like this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

无远思近则忧 2024-11-08 02:59:35

事务范围与 TransactionOptions 结合 IsolationLevel = IsolationLevel.ReadUncommissed 相当于 T-SQL 中的 WITH(NOLOCK),因此如果表未锁定,则不会发生死锁。 。

using (var scope = new TransactionScope(TransactionScopeOption.Required, new TransactionOptions(){ IsolationLevel = IsolationLevel.ReadUncommitted }))
{
}

Transaction scope combined with TransactionOptions IsolationLevel = IsolationLevel.ReadUncommitted is equivalent to WITH(NOLOCK) in T-SQL so if the table is not locked the deadlocks don't occur...

using (var scope = new TransactionScope(TransactionScopeOption.Required, new TransactionOptions(){ IsolationLevel = IsolationLevel.ReadUncommitted }))
{
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文