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

Chapter 14: Transactions and Locks
We have several different transaction isolation levels available. The default is READ COMMITTED. Using a
lower isolation level holds shared locks for a shorter duration than using a higher isolation level does,
thereby reducing locking contention.
No Open-Ended Transactions
This is probably the most commonsense of all the recommendations here, but it’s one that’s often violated
because of past practices.
One of the ways we used to prevent lost updates (mainframe days here, folks!) was just to grab the lock
and hold it until we were done with it. I can’t tell you how problematic this was (can you say yuck?).
Imagine this scenario (it’s a real-life example): Someone in your service department likes to use update
screens (exclusive locks) instead of display screens (shared locks) to look at data. He goes on to look at a
work order. Now his buddy calls and asks if he’s ready for lunch. “Sure!” comes the reply, and the service
clerk heads off to a rather long lunch (one to two hours). Everyone who is interested in this record is
now locked out of it for the duration of this clerk’s lunch.
Wait — it gets worse. In the days of the mainframe, you used to see the concept of queuing far more
often (it actually can be quite efficient). Now someone submits a print job (which is queued) for this
work order. It sits in the queue waiting for the record lock to clear. Since it’s a queue environment, every
print job your company has for work orders now piles up behind that first print job (which is going to
wait for that person’s lunch before clearing).
This is a rather extreme example, but I’m hoping that it clearly illustrates the point. Don’t ever create
locks that will still be open when you begin some form of open-ended process. Usually we’re talking
user interaction (like our lunch lover), but it could be any process that has an open-ended wait to it.
Summary
448
Transactions and locks are both cornerstones of how SQL Server works and, therefore, maximizing your
development of solutions in SQL Server.
By using transactions, you can make sure that everything you need to have happen as a unit happens, or
none of it does. SQL Server’s use of locks ensures that we avoid the pitfalls of concurrency to the maximum
extent possible (you’ll never avoid them entirely, but it’s amazing how close you can come with a
little — OK, a lot — of planning). By using the two together, you are able to pass what the database
industry calls the ACID test. If a transaction is ACID, then it has:
❑ Atomicity: The transaction is all or nothing.
❑ Consistency: All constraints and other data integrity rules have been adhered to, and all related
objects (data pages, index pages) have been updated completely.
❑ Isolation: Each transaction is completely isolated from any other transaction. The actions of one
transaction cannot be interfered with by the actions of a separate transaction.
❑ Durability: After a transaction is completed, its effects are permanently in place in the system.
The data is safe, in the sense that things such as a power outage or other non-disk system failure
will not lead to data that is only half written.