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

Chapter 14: Transactions and Locks
The SQL Server lock manager is that shopkeeper. When you come into the SQL Server store, the lock manager
asks what your intent is — what it is you’re going to be doing. If you say “just looking,” and no one
else already there is doing anything other than just looking, then the lock manager will let you in. If you
want to buy (update or delete) something, then the lock manager will check to see if anyone’s already there.
If so, you must wait, and everyone who comes in behind you will also wait. When you are let in to buy,
no one else will be let in until you are done.
By doing things this way, SQL Server is able to help us avoid a mix of different problems that can be created
by concurrency issues. We will examine the possible concurrency problems and how to set a transaction
isolation level that will prevent each, but for now, let’s move on to what can and cannot be locked, and
what kinds of locks are available.
What Problems Can Be Prevented by Locks
Locks can address four major problems:
❑ Dirty reads
❑ Non-repeatable reads
❑ Phantoms
❑ Lost updates
Each of these presents a separate set of problems and can be handled by a mix of solutions that usually
includes proper setting of the transaction isolation level. Just to help make things useful as you look back
at this chapter later, I’m going to include information on which transaction isolation level is appropriate
for each of these problems. We’ll take a complete look at isolation levels shortly, but for now, let’s first
make sure that we understand what each of these problems is all about.
Dirty Reads
434
Dirty reads occur when a transaction reads a record that is part of another transaction that isn’t complete
yet. If the first transaction completes normally, then it’s unlikely there’s a problem. But what if the transaction
were rolled back? You would have information from a transaction that never happened from the
database’s perspective!
Let’s look at it in an example series of steps:
Transaction 1
Command
Transaction 2
Command
BEGIN TRAN 3
Logical
Database
Value
UPDATE col = 5 BEGIN TRAN 3 5
Uncommitted
Database
Value
SELECT anything SELECT @var = col 3 5 5
ROLLBACK UPDATE anything
SET whatever = @var
3 5
What
Transaction 2
Shows