Supported Transaction Isolation Levels

NuoDB supports several levels of transaction isolation based on its use of Multi-Version Concurrency Control (MVCC). MVCC uses multiple versions of records to provide a consistent view of the data to each transaction and to prevent concurrent transactions from overwriting each other's changes. Under MVCC, readers do not block writers, and writers do not block readers.

Note: Different NuoDB drivers support transaction isolation levels in different ways. Consult the documentation for each driver you are using to find which isolation levels are supported by that driver.

NuoDB supports the following transaction isolation levels:

Isolation Level Brief Description Performance Trade-offs and Comments

This is the NuoDB default transaction isolation level. A transaction sees a snapshot of the database as it was when that transaction started plus any changes made in that transaction.

For more information, see CONSISTENT READ.

CONSISTENT READ raises exceptions and provides complete isolation from changes made by other transactions. Each transaction uses its own snapshot view of the database.
WRITE COMMITTED For read operations, each transaction sees the state of the database as it was when the transaction started plus its own changes, similar to CONSISTENT READ.
For write operations, including SELECT...FOR UPDATE, UPDATE and DELETE), each transaction reads the most recently committed version of a record, similar to READ COMMITTED.

WRITE COMMITTED maintains the complete isolation of each transaction for simple SELECT statements, but can breach the isolation for SELECT … FOR UPDATE, UPDATE, and DELETE statements. In an update intensive application, WRITE COMMITTED transactions may raise fewer exceptions when updating than CONSISTENT READ transactions.

Note: With the release of NuoDB 3.2, the WRITE COMMITTED isolation level has been deprecated.


Each transaction always reads the most recently committed version of a record.

For more information, see READ COMMITTED.

READ COMMITTED transactions offer no guarantee of isolation, but are very familiar to users of database systems that do not implement concurrency through MVCC. For applications that must run on multiple database systems, including those that are not based on MVCC, the READ COMMITTED level provides compatible behavior.
SERIALIZABLE Required for backward compatibility. For behavior, see CONSISTENT READ. See CONSISTENT READ.

Note: DDL statements are executed in separate system transactions and are not visible to the current transaction. In order for the current transaction to view or act upon the DDL statement(s) results, an explicit COMMIT statement must be performed before and after the DDL statement(s). The statements executed before and after the DDL statement(s) comprise their own separate transactions. The transaction that starts after the DDL statement(s) has a snapshot that includes the results of the DDL statement(s). A transaction in READ COMMITTED isolation mode sees the results of the DDL system transaction when the next statement executes and does not require an explicit COMMIT statement.

See the following topics: