 |
» |
|
|
|
|
|
5.43 Compare ru to the rr, cs and rc isolation levels
Key points
- Compared to RR, RU provides greater read and write concurrency to other
transactions:
- Greater read concurrency is achieved because other users can immediately read
rows that the RU transaction has read. In an RR transaction, users must wait until
the transaction terminates before they can read rows (or pages) that have
obtained SIX locks by the RR transaction.
- Greater write concurrency is achieved because other users can immediately
modify rows that the RU transaction has read. In an RR transaction, users must wait
until the transaction terminates before they can modify rows (or pages) that
have obtained S or SIX locks by the RR transaction.
- Compared to CS, RU also provides greater read and write concurrency to other
transactions:
- Greater read concurrency is achieved because other users can immediately read
rows that the RU transaction has read. In a CS transactions, users must wait until
the transaction moves the cursor before they can read rows (or pages) that have
obtained SIX locks by the CS transaction.
- Greater write concurrency is achieved because other users can immediately
modify rows that the RU transaction has read. In a CS transaction, users must wait
until the transaction moves the cursor before they can modify rows (or pages)
that have obtained S or SIX locks by the CS transaction.
- RU and RC both provide the same amount of read concurrency to other
transactions. The write concurrency of other transactions might be slightly
better using RU instead of RC.
- The same read concurrency is achieved because other users can immediately read
rows that either an RC or an RU transaction has read. An RU
transaction does provide higher read concurrency to itself, though, because it
does not have to wait to acquire an S lock before it can read data.
- Slightly greater write concurrency might be achieved using RU because other
users can immediately modify rows that the RU transaction has read. In an RC
transaction, users must wait until the transaction has released its S locks
(ALLBASE/SQL releases these locks immediately, but some overhead is still
involved that could technically slow other write transactions).
- RU is ideal for fuzzy reports and similar applications where the reading of
uncommitted data is not a major concern. Since RU does not
guarantee that a row will not change between the time you issue the
FETCH
statement and the time you issue an UPDATE WHERE CURRENT or a DELETE WHERE
CURRENT statement, you must issue a REFETCH statement and examine the
row's current values before you make any changes to it.
- RU is the most efficient isolation level in ALLBASE/SQL.
If you have data that only has readers (that is, you know in advance that no
user will ever modify it), then for optimal performance you can use RU
in a transaction that only accesses this data, because concurrency control
by ALLBASE/SQL is not really necessary. Keep in mind, though, that if
writers are ever acquired on the data, the isolation level of these RU
transactions may need to be changed to RC.
Page last updated on November 29, 1995
|
|
|
Printable version
