Beginning SQL

Chapter 11
Usually, the default isolation level is SERIALIZABLE. If you specify READ UNCOMMITTED, then the DBMS
assumes READ ONLY, and you cannot specify READ WRITE. If not otherwise specified, the DBMS assumes
READ WRITE. The purpose of these assumptions is twofold: to allow the DBMS to optimize its operation
and to protect inexperienced programmers from suffering the problems associated with transactions,
which are detailed in the next section.
Versioning
Versioning is a method of working around the issue of locks. The idea is that as modifications to records
are performed, versions of the data are made available to other users. Instead of just locking a user out,
the DBMS decides whether the other users need to see the modified or the unmodified version of the
data. There may in fact be several different versions of the data. The DBMS tracks the isolation levels
of the various transactions and makes decisions as to which version of the data any given transaction
should be allowed to see based on its isolation level. As far as I know, of all the major DBMSs, only
Oracle uses versioning.
Locks are inherently restrictive in nature and limit concurrent operations on data. If one transaction has
a write lock on data and another transaction has a SERIALIZABLE isolation level set, that transaction
cannot even see the locked data. Thus that transaction simply halts processing until the data it needs
to see is finally written. In a versioning system, as soon as the first transaction makes its modifications to
the data, the second transaction may be allowed to see the modified or unmodified data, depending on
what the DBMS decides is applicable to the operations the transaction is doing and its isolation level.
Thus the second transaction can keep right on processing.
Versioning databases can, under the right circumstances, increase the number of concurrent transactions
executing in parallel. Because the transactions do not wait for locks to release, they can continue whatever
they are doing as if each process had exclusive access to the data. Unfortunately, there is significant
overhead in tracking whether the various processes did in fact interfere with each other, and in those
cases, the system must undo the damage and start over from the point where the interference occurred.
Problem Examples
In order to understand some of the problems that transactions help to prevent and that isolation levels
address, it is useful to discuss a well-known set of problems. These problems are so well known, in fact,
that they have been given names and are routinely discussed when learning transactions. The following
text identifies these problems, provides you with a scenario in which you might encounter each one, and
classifies the isolation level you should set in order to prevent them from occurring. Following the discussion
of the problems is a table that summarizes the problems and how the various isolation levels
affect the problem.
The Lost Update
320
The lost update problem illustrates what can occur when two programs read the same data from a table,
use that data in calculations, and then try to update that data. A SERIALIZABLE isolation level helps you
to prevent the lost update. The following situation gives you an idea of how the lost update can pop up
in the real world.