|
Isolation Level
|
XDB Server provides six levels of isolation so users can control the tradeoff between concurrency and consistency:
- Concurrency is the ability for multiple transactions to access database resources simultaneously.
- Consistency is the degree to which changes made by one user have no negative effects on other transactions in a multiuser environment.
Within the maximum degree of consistency and minimum degree of concurrency, the isolation levels are:
|
| |
Exclusive Use
|
The entire database is locked for exclusive use of the current transaction. |
| |
Repeatable Read
|
All locks are held until commit point to guarantee that transactions can be done serially. |
| |
Cursor Stability
|
Exclusive (read-write) locks are held until commit, and shared (read-only) locks are released when the next record is accessed. |
| |
Lock Current
|
Only the current record is locked. This level should be used with AUTOCOMMIT ON, or for read-only operations. |
| |
Dirty Read
|
No locks are obtained. Uncommitted record changes are read regardless of locks (other than database locks). A DR transaction is read-only; records cannot be modified. |
| |
Snapshot Read
|
At this level, a snapshot of the data is made at the time of execution. Other users can make changes to the data without waiting for the transaction to complete and the user is ensured that the data will be the same for the life of the transaction. An SR transaction is read-only |
|
Time-out Interval
|
This is the length of time (in seconds) to wait before retrying, when a lock conflict occurs. |
|
AutoCommit
|
With AUTOCOMMIT on, an SQL command is committed as soon as it is successfully completed. If AUTOCOMMIT is off, the user needs to explicitly commit transactions by issuing an SQL COMMIT command or by selecting COMMIT from a menu in an application. AUTOCOMMIT is not supported against XDB Link locations. |
|
Backward Logging
|
This option is used only when accessing XDB Server Versions 3.x and 4.x. If using XDB Server Version 5.0 or higher, logging is automatic and this option is ignored. To perform a rollback operation when using the older XDB Server versions, it is necessary to maintain a log of before images of all changes made to the database during a transaction. This information is stored in a backward log. The backward log contains only the information necessary to roll back the current transaction. Every time a transaction is committed or rolled back, the backward log is erased. When the log is turned off, rollback is not possible, but changes to the database take less time because before images are not written to the log.
For more about backward logging on the older XDB Server versions, see the Backup and Recover chapter of the XDB Server Administration Guide for the XDB Server version you are using.
|
