2

我最近一直在处理我们的应用程序中的一些死锁情况，并且有一个对我来说似乎很奇怪的新案例。错误日志显示了这一点（没有执行堆栈，我相信此时无关紧要）：

deadlock-list
  deadlock victim=process84db88
   process-list
    process id=process84db88 taskpriority=0 logused=0 waitresource=KEY: 11:72057594409844736 (8194443284a0) waittime=4685 ownerId=3632385974 transactionname=SELECT lasttranstarted=2011-12-07T16:21:16.287 XDES=0x32f68fca0 lockMode=S schedulerid=6 kpid=6392 status=suspended spid=93 sbid=0 ecid=0 priority=0 trancount=0 lastbatchstarted=2011-12-07T16:21:16.287 lastbatchcompleted=2011-12-07T16:21:16.287 clientapp=.Net SqlClient Data Provider hostname=DE-1809 hostpid=4156 loginname=XXX isolationlevel=read committed (2) xactid=3632385974 currentdb=11 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
     executionStack
      ........   
    process id=process47bdc8 taskpriority=0 logused=240604 waitresource=KEY: 11:72057594409844736 (829df5d1e88e) waittime=4681 ownerId=3632397262 transactionname=UPDATE lasttranstarted=2011-12-07T16:21:26.100 XDES=0x2f00b93c0 lockMode=X schedulerid=1 kpid=6568 status=suspended spid=88 sbid=0 ecid=0 priority=0 trancount=2 lastbatchstarted=2011-12-07T16:21:25.640 lastbatchcompleted=2011-12-07T16:21:25.640 clientapp=.Net SqlClient Data Provider hostname=DE-1809 hostpid=4156 loginname=XXX isolationlevel=read committed (2) xactid=3632397262 currentdb=11 lockTimeout=4294967295 clientoption1=673316896 clientoption2=128056
     executionStack
      .........  
   resource-list
    keylock hobtid=72057594409844736 dbid=11 objectname=dbo.OurTable indexname=PK_OurTable id=lock1d9aa0b00 mode=X associatedObjectId=72057594409844736
     owner-list
      owner id=process47bdc8 mode=X
     waiter-list
      waiter id=process84db88 mode=S requestType=wait
    keylock hobtid=72057594409844736 dbid=11 objectname=dbo.OurTable indexname=PK_OurTable id=lock1a56cb580 mode=U associatedObjectId=72057594409844736
     owner-list
      owner id=process84db88 mode=S
     waiter-list
      waiter id=process47bdc8 mode=X requestType=convert

锁定发生在我们其中一张表的同一聚集索引中的键上。让我有点困惑的是资源列表中最后一个键锁行中的模式。

它说：mode=U而相应所有者列表中的所有者说：mode=S。

我应该怎么读这个？这两种模式通常是相同的。这些模式有何不同？

4

2 回答 2

3

我会将其解释为在该资源上process47bdc8具有U锁定并且正在等待将其转换为X锁定但不能因为process84db88已经具有S锁定的意思。

S锁和U锁是兼容的。

于 2011-12-09T11:20:02.583 回答
1

来自MSDN的这句话可能提供了一个解释：

为了避免这种潜在的死锁问题，使用了更新 (U) 锁。一次只有一个事务可以获取资源的更新 (U) 锁。如果事务修改了资源，则更新 (U) 锁将转换为排他 (X) 锁。否则，锁将转换为共享模式锁。

因此，请求共享锁的一个事务（可能是第一个事务）最终会持有更新锁。如果事务想要进行更新，更新锁只是为事务提供了转换为排他锁的选项。

如果两个事务读取然后写入同一行，则此机制会有所帮助。在您的情况下，有两行在起作用。第一个事务在 A 行上有一个排他锁，正在等待转换为 B 行上的排他锁。第二个事务在 B 行上有一个共享锁，这实际上是一个更新锁，它正在等待行上的排他锁一种。

于 2011-12-09T08:05:32.513 回答