Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

CHAPTER 7 ■ CONCURRENCY AND MULTI-VERSIONING 239
Lost Updates: Another Portability Issue
A common use of REPEATABLE READ in databases that employ the shared read locks could be for
lost update prevention.
■Note Lost update detection and solutions to the lost update problem are discussed in Chapter 6.
If we have REPEATABLE READ enabled in a database that employs shared read locks (and not
multi-versioning), lost update errors cannot happen. The reason lost updates cannot happen
in those databases is because the simple act of selecting the data left a lock on it, once read by
our transaction, that data cannot be modified by any other transaction. Now, if your application
assumes that REPEATABLE READ implies “lost updates cannot happen,” you are in for a
painful surprise when you move your application to a database that does not use shared read
locks as an underlying concurrency-control mechanism.
While this sounds good, you must remember that leaving the shared read locks behind on
all data as it is read will, of course, severely limit concurrent reads and modifications. So, while
this isolation level in those databases provides for lost update prevention, it does so by removing
the ability to perform concurrent operations! You cannot always have your cake and eat
it too.
SERIALIZABLE
This is generally considered the most restrictive level of transaction isolation, but it provides
the highest degree of isolation. A SERIALIZABLE transaction operates in an environment that
makes it appear as if there are no other users modifying data in the database. Any row we read
is assured to be the same upon a reread, and any query we execute is guaranteed to return the
same results for the life of a transaction. For example, if we execute
Select * from T;
Begin dbms_lock.sleep( 60*60*24 ); end;
Select * from T;
the answers returned from T would be the same, even though we just slept for 24 hours (or we
might get an ORA-1555: snapshot too old error, which is discussed in Chapter 8). The isolation
level assures us these two queries will always return the same results. Side effects (changes)
made by other transactions are not visible to the query regardless of how long it has been
running.
In Oracle, a SERIALIZABLE transaction is implemented so that the read consistency we
normally get at the statement level is extended to the transaction.
■Note As noted earlier, there is also an isolation level in Oracle denoted READ ONLY. It has all of the qualities
of the SERIALIZABLE isolation level, but it prohibits modifications. It should be noted that the SYS user
(or users connected as SYSDBA) cannot have a READ ONLY or SERIALIZABLE transaction. SYS is special in
this regard.