 |
» |
|
|
|
|
|
5.41 Compare rc to the rr and cs isolation levels
Key points (continued)
- Compared to RR, RC provides greater read and write concurrency to other
transactions:
- Greater read concurrency is achieved because other users can read rows
immediately after an RC transaction has read them. 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 modify rows
immediately after an RC transaction has read them. 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, RC also provides greater read and write concurrency to other
transactions:
- Greater read concurrency is achieved because users can read rows
immediately after an RC transaction has read them. In a CS transaction, 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 modify rows
immediately after an RC transaction has read them. 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.
- RC automatically acquires and releases intention locks during every FETCH.
CS only releases appropriate intention locks when the cursor moves.
In a CS transaction, the table level intention lock is always retained. If
the cursor stays on the same page when the next FETCH is issued, the page
level intention lock is also retained (instead of being released and
reacquired). As a result, CS may incur less lock management overhead (and
therefore be more efficient) than RC. Of course, some concurrency might be
lost by using CS instead of RC in this situation.
- Use the RC isolation level for transactions that contain non-updatable
cursors if you simply need to view a snapshot of committed data and if you
don't need to make data modifications based on the values returned by the
cursor.
- Use the RC isolation level for transactions that contain updatable cursors
that need to scan through rows of committed data in a table, especially when a
relatively large amount of time elapses between fetches. Since RC
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.
Page last updated on November 29, 1995
|
|
|
Printable version
