The isolation level affects the concurrency between sessions that access the same set of data. The following tables show the types of phenomena that can occur without appropriate isolation-level controls.
Transaction 1 Write(a) Roll Back
Transaction 2 Read(a)
Transaction 1 Read(a) Read(a)
Transaction 2 Write/Delete(a) Commit
Transaction 1 Select(criteria) Select(criteria)
Transaction 2 Update/Create Commit
To determine which of the following isolation levels the user or application specifies, the access method can call either the mi_tab_isolevel() or mi_scan_isolevel() function.
Isolation Level | Type of Read Prevented |
---|---|
Serializable | Dirty Read, Nonrepeatable Read, Phantom Read |
Repeatable read or Cursor Stability | Dirty Read, Nonrepeatable Read |
Read Committed | Dirty Read |
Read Uncommitted | None |
For more information about how applications use isolation levels, consult the IBM Informix: Guide to SQL Reference, IBM Informix: Guide to SQL Syntax, and IBM Informix: Guide to SQL Tutorial. For information about determining isolation level, refer to mi_scan_isolevel() or mi_tab_isolevel() in Descriptor Function Reference.
The database server automatically enforces Repeatable Read isolation under the following conditions:
To find out how to turn on user-data logging with the access method, refer to Activating Automatic Controls in Sbspaces. To find out how to provide for logging with ONCONFIG parameters, refer to your IBM Informix: Administrator's Guide.
The access method must provide the code to enforce isolation levels if users require Serializable isolation. The database server does not provide support for full Serializable isolation.