 |
» |
|
|
|
|
|
5.42 Describe the read uncommitted isolation level
Key points
- Read Uncommitted (RU) -- S locks are not acquired by the transaction when
it reads data.
- An RU transaction does not have to wait for an incompatible lock to be
released by another transaction before it can read data. You
can read rows (or pages) that have been modified (locked with an
X lock), or are being modified (locked with an SIX lock) by some
other transaction that has not yet committed its changes. The other
transaction may eventually decide to issue a
ROLLBACK WORK and cancel its
changes.
- Reads made in an RU transaction are also known as dirty reads.
- If you need to update or delete a row using a cursor in an RU transaction,
you must use the
REFETCH statement to verify that the row has not changed
between the FETCH statement and the UPDATE WHERE CURRENT or the DELETE WHERE
CURRENT statement. After the REFETCH, examine the row's current value
before updating or deleting it. This action ensures that your transaction
does not accidentally overwrite changes made by some other transaction. A row
cannot be changed by another transaction between the time you issue the
REFETCH statement and the time you issue an UPDATE WHERE CURRENT statement in
the same transaction, because the REFETCH statement obtains an SIX lock.
- The
UPDATE WHERE CURRENT and DELETE WHERE CURRENT statements will obtain an
X lock at the row level on a PUBLICROW table and at the page level on a PUBLIC
table. Appropriate intention locks are also acquired.
- By default under any isolation level, X locks and IX intention locks on pages
containing modified rows are retained until the transaction ends. SIX locks
obtained by the
REFETCH command are also retained until the transaction ends,
if they are not converted to X locks.
Page last updated on November 29, 1995
|
|
|
Printable version
