ISOLATION determines how far to isolate an application from the effects of other running applications.

(RR)  Repeatable read. Ensures that:
Your application does not read a row that another process has changed until that process releases that row.
Other processes do not change a row that your application reads until your application commits or terminates.

(RS)  Read stability. Ensures that:
Your application does not read a row that another process has changed until that process releases that row.
Other processes do not change a row that satisfies the application's search condition until your application commits or terminates. It does allow other application processes to insert a row, or to change a row that did not originally satisfy the search condition.
If the server does not support RS, it uses RR.

(CS)  Cursor stability. Ensures, like repeatable read, that your application does not read a row that another process changes until that process releases that row. Unlike repeatable read, cursor stability does   not prevent other applications from changing rows that your application reads before your program commits or terminates.

(UR)  Uncommitted read. Unlike repeatable read and cursor stability, does not ensure anything. With the exception of LOB data, uncommitted read avoids acquiring locks on data and allows:
Other processes change any row your application reads during the unit of work.
Your application read any row that another process has changed, even if the process has not committed the row.

You can use this option only with a read-only operation: SELECT, SELECT INTO, or FETCH using a read-only cursor. If you specify ISOLATION(UR) for any other operation, DB2 uses ISOLATION(CS) for that operation.