Isolation levels

Isolation levels define the degree to which the operations in one transaction are visible to the operations in other concurrent transactions. UltraLite uses the default isolation level, read_committed, for connections. The default UltraLite isolation level aids data consistency by isolating uncommitted rows.

This isolation level...	Has these characteristics...
0—read_uncommitted	Allow dirty reads, non-repeatable reads, and phantom rows. No guarantee that concurrent transactions will not modify row or roll back changes to rows
1—read_committed	Allow non-repeatable reads and phantom rows Prevent dirty reads No guarantee that query results will not change during transactions

You can change the isolation level from read_committed to read_uncommitted using one of following approaches:

Use the SET OPTION SQL statement and the isolation_level database option.

For example, the following statement sets the isolation level to read uncommitted:
SET OPTION isolation_level = 'READ_UNCOMMITTED'
For the UltraLite C++ API, use the ULConnection.SetDatabaseOption method to change the isolation level.

For the UltraLite.NET API, use the ULConnection.BeginTransaction or ULDatabaseSchema.SetDatabaseOption methods to create a transaction with the read_committed isolation level.

For the UltraLiteJ API, use the Connection.setOption method.

Note

UltraLite Java edition databases only support the read_uncommitted isolation level. See Data synchronization on a BlackBerry smartphone.

Concurrency and locking for UltraLite Java edition databases

Locking Two different connections cannot modify the same row concurrently. If two connections attempt to operate on the same row, the second connection receives an error and is prohibited from modifying the row until the first connection commits or rolls back its current transaction.
Visibility One connection's operation on the database is immediately visible to other connections.

Isolation levels

Note

Concurrency and locking for UltraLite Java edition databases

See also