Update and Exclusive locks mostly are used for Data Manipulating Language delete and update. Fisrt of all, let’s have a quick glance below:
use tempdb set nocount on if OBJECT_ID('abc') is not null drop table abc create table abc(id int) insert into abc values(1),(2),(3) begin transaction delete abc where id = 1 exec sp_lock @@spid rollback transaction /* spid dbid ObjId IndId Type Resource Mode Status ------ ------ ----------- ------ ---- -------------------------------- -------- ------ 52 2 1365579903 0 RID 1:172:0 X GRANT 52 2 1365579903 0 PAG 1:172 IX GRANT 52 2 1365579903 0 TAB IX GRANT 52 1 439672614 0 TAB IS GRANT */
From result, you can ignore the line 17, the IS lock on that line on master database (dbid = 1) is look up values in the master database, like RID, PAG, TAB. While data being deleted, there’s on IX (Intent Exclusive) lock granted to the table (TAB), IX lock on the page where the records located, and X (eXclusive) lock on the row. After transaction is rolledback or committed, the lock on those resources will be release. Seem like there is nothing to the Update lock. That’s true if you use this tool or sys.dm_trans_locks to check the locking behaviour. Your will see more locks by using below.