加入收藏 | 设为首页 | 会员中心 | 我要投稿 安卓应用网 (https://www.0791zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 数据库 > MsSql > 正文

readcommitted隔离级别是否会导致死锁(Sql Server)?

发布时间:2020-05-25 10:23:08 所属栏目:MsSql 来源:互联网
导读:我对死锁的理解是 – 两个试图争用相同资源的进程 – 通常是两个进程试图“写”到同一行数据.如果所有进程都在读取数据 – 而另一个进程正在更新数据,那么资源争用情况如何?然而,在我们的数据库中,设置为默认事务级别“ReadCommitted”,我们看到了几个死锁异

我对死锁的理解是 – 两个试图争用相同资源的进程 – 通常是两个进程试图“写”到同一行数据.如果所有进程都在读取数据 – 而另一个进程正在更新数据,那么资源争用情况如何?然而,在我们的数据库中,设置为默认事务级别“ReadCommitted”,我们看到了几个死锁异常.
ReadComitted definitin – 无法读取已修改(但尚未提交)的数据.这很好 – 但是如果遇到这种“脏读”,SQL Server会抛出死锁异常吗?
有没有人对这种情况有真实的经验?我找到了一篇博文(由stackoverflow开发人员发布,并没有减少:)声称这可能是真的.

谢谢

解决方法

是的,它可能发生.想象一下,你有两个进程,每个进程都有自己的事务.第一次更新TableA然后尝试更新TableB.第二次更新TableB然后尝试更新TableA.如果你运气不好,两个进程都会设法完成第一步,然后无限期地等待另一个进程,以完成第二步.

顺便说一句,这是避免死锁的最常见方法之一:按照更新表的顺序保持一致.如果两个进程首先更新TableA然后更新TableB,则不会发生死锁.

(编辑:安卓应用网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读