锁定问题 - 'U'锁定与'X'锁定

Question

我有几个关于Update(U)锁和Exclusive(X)锁的问题.

1)我是否正确当资源即将更新时,"X"锁被置于资源上？

2)我对U锁有点模糊.我是否正确读取资源时应用了U锁,SQL Server认为以后可能需要更新资源？如果这是正确的,那么只有在事务上下文中进行读取时才会应用"U"锁吗？我想我正在尝试理解在什么情况下SQL Server认为它可能需要稍后更新它刚刚读取的行.

谢谢 - 兰迪

Answer 1

1)我是否正确当资源即将更新时,"X"锁被置于资源上？

是.

2)我对U锁有点模糊.我是否正确读取资源时应用了U锁,SQL Server认为以后可能需要更新资源？如果这是正确的,那么只有在事务上下文中进行读取时才会应用"U"锁吗？我想我正在尝试理解在什么情况下SQL Server认为它可能需要稍后更新它刚刚读取的行.

U锁与读锁兼容,但彼此X不兼容,即使读锁也不兼容锁.

U锁由放置DML查询(UPDATE,DELETE,MERGE),而扫描表中的行(没有决定更新是尚未作出),而X当判定为更新的行锁放置.

在READ COMMITTED隔离模式下,在评估记录保持原样后,更新锁定被取消,在更高的隔离模式下,它们一直保留到事务结束.

实际上U锁和S锁有点复杂,它们是不对称的:U与S兼容,但S与U不兼容.这样即使资源上有S锁,也可以授予U锁.进一步的S锁请求将被阻止,因为它们与U不兼容.当作者需要实际进行写入时,他可以将U升级到X而不会被S锁偷偷摸摸地饿死. (3认同)
http://amzn.to/bSwmW9 页。410：“更新锁模式将死锁转换为锁等待。它被选择为非对称的：更新与共享兼容，但共享与更新不兼容。这允许更新者读取，但会延迟其他事务读取者和更新者，因为交易即将更新记录”。至少，理论上是这样的。在 SQL Server 中，它们实际上的行为就像您所解释的那样。 (2认同)