The isolation level is used only within a transaction.

The behavior of updates on locked data depends on the value of the LOCKTIMEOUT variable of DB2. If this variable is set to -1, then the update waits until the lock is released. If LOCKTIMEOUT is set to 0, the update fails immediately; and if it is set to a number greater than 0, the update waits for the specified seconds before failing.

An isolation level determines how data is locked or isolated from other processes while that data is being accessed.these can be specified in 4 ways1)RR(Repeatable read) 2)RS(Read stability) 3)UR(uncommited read) 4)cs(cursor stability)
1. Cursor Stability : lock is retained when untill the cursor moves from one record in one page to the next record in another page. Provides WRITE Integrity.

Isolation Level Serializable Repeatable read or Cursor Stability Read Committed Read Uncommitted

Type of Read Prevented Dirty Read, Nonrepeatable Read, Phantom Read Dirty Read, Nonrepeatable Read Dirty Read None

Table 1. Summary of isolation levels Isolation Level Access to uncommitted data Not possible Not possible Not possible Possible Nonrepeatable reads Phantom read phenomenon

Repeatable Read (RR) Read Stability (RS) Cursor Stability (CS) Uncommitted Read (UR)

Not possible Not possible Possible Possible

Not possible Possible Possible Possible

Table 2. Guidelines for choosing an isolation level Application Type High data stability required High data stability not required CS UR

Read-write transactions Read-only transactions

RS RR or RS

Cursor stability does not just apply to when you open a cursor. If there are multiple rows that DB2 needs to read to get the answer set, all those rows are in the internal cursor and DB2 needs to obtain a Share (read) lock on each row. Using cursor stability means that when doing a select, DB2 will only hold a Share lock on the row being read, and not maintain that lock until the next commit (or other event that would cause all locks to be released). Maybe the same as Serializable, but I am not sure. __________________

You can specify an isolation level for the following SQL statements:

o o o o o

SELECT SELECT INTO Searched DELETE INSERT Searched UPDATE

DECLARE CURSOR

Static SQL:

If an isolation clause is specified in the statement, then the value of that clause is used. If no isolation clause is specifed in the statement, then the isolation level used is the one specified for the package at the time when the package was bound to the database.

Dynamic SQL:

If an isolation clause is specified in the statement, then the value of that clause is used. If no isolation clause is specifed in the statement, and a SET CURRENT ISOLATION statement has been issued within the current session, then the value of the CURRENT ISOLATION special register is used. If no isolation clause is specifed in the statement, and no SET CURRENT ISOLATION statement has been issued within the current session, then the isolation level used is the one specified for the package at the time when the package was bound to the database.

Comparison of isolation levels

NC Can the application see uncommitted changes made by other application processes? Yes

UR Yes No

CS No No

RS No No

RR No No

Can the application update uncommitted changes No made by other application processes? Can the re-execution of a statement be affected by other application processes? See phenomenon P3 Yes (phantom) below. Can updated rows be updated by other application processes? Can updated rows be read by other application processes that are running at an isolation level other than UR and NC? Can updated rows be read by other application processes that are running at the UR or NC isolation level? Can accessed rows be updated by other Yes

Yes

Yes

Yes

No

No

No

No

No

Yes

No

No

No

No

Yes Yes

Yes Yes

Yes Yes

Yes No

Yes No

NC application processes?

UR

CS

RS

RR

For RS, accessed rows typically means rows selected. For RR, see the product-specific documentation. See phenomenon P2 (nonrepeatable read) below.
Can accessed rows be read by other application processes? Yes Yes Yes Yes Yes

Can current row be updated or deleted by other See Note See Note See Note application processes? See phenomenon P1 (dirtyNo below below below read) below. Note: This depends on whether the cursor that is positioned on the current row is updatable:

No

If the cursor is updatable, the current row cannot be updated or deleted by other application processes If the cursor is not updatable, o For UR or NC, the current row can be updated or deleted by other application processes. o For CS, the current row may be updatable in some circumstances.

Examples of Phenomena: P1 Dirty Read. Unit of work UW1 modifies a row. Unit of work UW2 reads that row before UW1 performs a COMMIT. UW1 then performs a ROLLBACK. UW2 has read a nonexistent row. P2 Nonrepeatable Read. Unit of work UW1 reads a row. Unit of work UW2 modifies that row and performs a COMMIT. UW1 then re-reads the row and obtains the modified data value. P3 Phantom. Unit of work UW1 reads the set of n rows that satisfies some search condition. Unit of work UW2 then INSERTs one or more rows that satisfies the search condition. UW1 then repeats the initial read with the same search condition and obtains the original rows plus the inserted rows.