The isolation level determines how data is locked (isolated),
from other processes while it is being accessed.
DB2 supports the following isolation levels:
- Repeatable read
- All rows retrieved by an application are locked within a unit of
work. As a result, a query issued twice within the same unit of work
while a cursor is opened will provide the same result each time.
- Read stability
- A qualifying row that is read during a unit of work is not changed by
other application processes until the unit of work completes, and any row
changed by another process is not read until the change is committed by that
process. As a result, a query issued twice within the same unit of work
may return additional "phantom" rows.
- Cursor stability
- A row accessed by a transaction is locked while the cursor is positioned
on that row. (If a row's data is changed, the lock is held until
the change is committed.) As a result, a query issued twice within the
same unit of work might not produce the same results.
- Uncommitted read
- An application can access the uncommitted changes of other
transactions. It is most often used on read-only tables for select
statements.
For more information,
see
the section on concurrency in the Administration Guide.
[ Top of Page |
Table of Contents |
Glossary |
Index ]
[ DB2 List of Books |
Search the DB2 Books ]