Update lock并不是一种单独的锁，而是shared lock和exclusive lock的混合体。
当数据库执行更新（insert, update, delete）操作时，会去尝试获得update lock. 整个更新操作可以分为两步：1 定位需要更新的数据，2 执行更新操作.
定位数据的步骤就是数据搜索的过程，我们可以将其想像成select，这时sqlserver会去尝试获得shared lock,
如果第一步成功，就会进入第二个阶段时，去获得exclusive lock，将之前获得的update lock转化(convert)成exclusive lock. 由于update lock的这种设计，导致它非常难被观察到,在事务中执行一条更新语句，你最终看到的只是转化后的exclusive lock了。
现在介绍如何观察update lock.
因为update lock转化成exclusive lock后就会消失，我们可以想办法阻止其转化，也就是成功获得update lock将后续操作阻塞(block).
根据锁的兼容性我们知道shared lock 和update lock之间兼容的，而shared lock和exclusive lock是冲突的。
首先我们让session A在资源S上添加了shared lock，接下来在session B对资源S进行更新操作，
这样，session B就可以更共的获得update lock（定位数据时），而当尝试进行转换成exclusive lock时就会被阻塞。 代码如下：
create table t(col int)
insert t values(1)
|
Step |
Session A |
Session B |
|
1 |
set transaction isolation level repeatable read begin tran select * from t |
|
|
2 |
update t set col=5 -- this sql statement will be block | |
|
3 |
select request_session_id, resource_type,resource_description, resource_associated_entity_id,request_mode, request_type,request_status from sys.dm_tran_locks |
我们可以得到类似如下的结果
可以看到，session B（应对session 55）已经获得了update lock（第一行request_status为GRANT）,在尝试转换时被阻塞了(第三行 request_status为convert)
相关
http://www.cnblogs.com/stswordman/archive/2009/01/06/1370269.html