Beginning SQL

Chapter 11
When discussing locking, the phrases optimistic and pessimistic inevitably come up. Optimistic locking
generally presumes that transactions do not interfere with each other and thus prefer less restrictive
locking strategies. Pessimistic locking assumes that transactions definitely interfere with each other and
thus presumes more restrictive locking strategies. In general, locks work very well as long as the locks
are of short duration, usually milliseconds or seconds. If locks last hours or days, they can tie a database
up in knots, which is where versioning (discussed shortly) comes into play.
Isolation Levels
With some DBMSs, you can set the isolation level, which simply means the level of isolation between users
of the database and their transactions and how much they are allowed to interfere with each other. To this
point, this chapter has discussed transactions as if they were absolutely isolated from each other, but this
may not be necessary or even desirable. Remember that transactions and locks have costs associated with
them, and to force absolute isolation at all times would cause maximum cost. However, insufficient isolation
between transactions can cause serious problems, displaying inconsistent views of the data and even
causing data corruption. It is important to understand the issues that insufficient isolation can cause, as
well as issues that unnecessary isolation causes.
SET TRANSACTION
The SQL2 standard provides an actual SET TRANSACTION statement that tells the DBMS which isolation
level the transaction that follows uses. You can use this statement only as the first statement of a transaction,
and thus you cannot change it in the middle of a transaction. It is possible to change levels at the
beginning of any transaction, allowing different processes the freedom to select the isolation level necessary
for the transaction that follows. Each level has its uses and should be used where applicable. After
all, the lower the isolation level, the lower the impact on the database, on other users and processes, and
on the hardware and software that implement the database platform.
Isolation levels are set using SQL code as shown below. Only one of the isolation levels can be set at any
given time, and it remains in effect until explicitly changed. Generally, if no SET TRANSACTION statement
is issued, the SERIALIZABLE level is in effect.
SET TRANSACTION ISOLATION LEVEL ISOLATION LEVEL
BEGIN TRANSACTION
The four isolation levels are discussed in the following sections.
SERIALIZABLE
318
A SERIALIZABLE isolation is essentially the maximum isolation possible. At this level, the DBMS guarantees
that concurrently processing transactions operate as if they occurred in sequence (serially). SERI-
ALIZABLE isolation is the default level in the ANSI standard, and this is how most database users expect
transactions to perform. If a transaction sequence needs to be able to read a specific set of data twice during
the transaction and return exactly the same set of data, SERIALIZABLE is the level that you need to
use. It is implemented by using the following statement:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION