Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Exclusive Locks
Exclusive locks are just what they sound like. Exclusive locks are not compatible with any other lock.
They cannot be achieved if any other lock exists, nor will they allow a new lock of any form to be created
on the resource while the exclusive lock is still active. This prevents two people from updating, deleting,
or whatever at the same time.
Update Locks
Update locks are something of a hybrid between shared locks and exclusive locks. An update lock is a
special kind of placeholder. Think about it — in order to do an update, you need to validate your WHERE
clause (assuming there is one) to figure out just what rows you’re going to be updating. That means that
you only need a shared lock, until you actually go to make the physical update. At the time of the physical
update, you’ll need an exclusive lock.
Update locks indicate that you have a shared lock that’s going to become an exclusive lock after you’ve
done your initial scan of the data to figure out what exactly needs to be updated. This acknowledges the
fact that there are two distinct stages to an update:
1. The stage where you are figuring out what meets the WHERE clause criteria (what’s going to be
updated). This is the part of an update query that has an update lock.
2. The stage where, if you actually decide to perform the update, the lock is upgraded to an exclusive
lock. Otherwise, the lock is converted to a shared lock.
What’s nice about this is that it forms a barrier against one variety of deadlock. A deadlock is not a type of
lock in itself, but rather a situation where a paradox has been formed. A deadlock arises if one lock can’t
do what it needs to do in order to clear because another lock is holding that resource — the problem is
that the opposite resource is itself stuck waiting for the lock to clear on the first transaction.
Without update locks, these deadlocks would crop up all the time. Two update queries would be running
in shared mode. Query A completes its query and is ready for the physical update. It wants to escalate
to an exclusive lock, but it can’t because Query B is finishing its query. Query B then finishes the
query, except that it needs to do the physical update. In order to do that, Query B must escalate to an
exclusive lock, but it can’t because Query A is still waiting. This creates an impasse.
Instead, an update lock prevents any other update locks from being established. The instant that the second
transaction attempts to achieve an update lock, they will be put into a wait status for whatever the lock
timeout is — the lock will not be granted. If the first lock clears before the lock timeout is reached, then the
lock will be granted to the new requester and that process can continue. If not, an error will be generated.
Update locks are compatible only with shared locks and intent shared locks.
Intent Locks
Chapter 14: Transactions and Locks
An intent lock is a true placeholder and is meant to deal with the issue of object hierarchies. Imagine a situation
where you have a lock established on a row, but someone wants to establish a lock on a page or
extent, or modify a table. You wouldn’t want another transaction to go around yours by going higher up
the hierarchy, would you?
Without intent locks, the higher-level objects wouldn’t even know that you had the lock at the lower
level. Intent locks improve performance, as SQL Server needs to examine intent locks only at the table
439