原作(Wei.Xiao)
很多人都认为SQL Server的锁授予是FIFO(先进先出)以避免饥饿问题(又叫哲学家问题)的。想想吧，你在超市等待结帐的时候，如果别人可以随便插队的话，你还能离开超市吗？
我的朋友Santtu 是一个lock manager的专家，他告诉我SQL Server做得比这要聪明。FIFO有一个缺点，它并不总是允许最大的并发度。SQL Server 2005的lock manager就做到了在避免饥饿的情况下允许了尽可能大的并发度。
举个例子说明：Transaction T1在表Foo上有个IX lock，Transaction T2也在表Foo运行了一个查询并且指定了TABLOCK。显然T2会被T1所阻塞，S lock和IX lock是不能并存的。Transaction T3在表Foo上有个查询，但没有使用锁定提示。T3的IS请求就会在T2的S请求之前被授予，因为IS和IX, S都不冲突。但是如果Transaction T4要在表Foo上作一个update的话，就会被T2所阻塞，因为T4的IX lock和T2的S lock是不能并存的，T2先来，所以T2会先被执行。
打印 | 张贴于 2006-01-06 09:39:00 | Tag:暂无标签
留言反馈
应该是T3请求的锁如果和T2请示的锁兼容的话，T3就有可能在T2获得锁之前，获得它要的锁
In SQL Server 2000, both T3 and T4 would have been blocked behind T2’s request.