Open Source RDBMS - Seamless, Scalable, Stable and Free

한국어 | Login |Register

Versions available for this page: CUBRID 8.2.1 |  CUBRID 8.3.0 |  CUBRID 8.3.1 |  CUBRID 8.4.0 |  CUBRID 8.4.1 |  CUBRID 8.4.3 |  CUBRID 9.0.0 | 



Database Concurrency

If there are multiple users with read and write authorization to a database, possibility exists that more than one user will access the database simultaneously. Controlling access and update in multi-user environment is essential to protect database integrity and ensure that users and transactions should have accurate and consistent data. Without appropriate control, data could be updated incorrectly in the wrong order.

Like most commercial database systems, CUBRID adopts serializability, an element that is essential to maintaining data concurrency within the database. Serializability ensures no interference between transactions when multiple transactions are executed at once. It is guaranteed more with the higher isolation level. This principle is based on the assumption that database consistency is guaranteed as long as transaction is executed automatically. This will be covered in the Lock Protocol section in detail.

The transaction must ensure database concurrency, and each transaction must guarantee appropriate results. When multiple transactions are being executed at once, an event in transaction T1 should not affect an event in transaction T2. This means isolation. Transaction isolation level is the degree to which a transaction is separated from all other concurrent transactions. The higher isolation level means the lower interference from other transactions. The lower isolation level means the higher the concurrency. A database determines whether which lock is applied to tables and records based on these isolation levels. Therefore, can control the level of consistency and concurrency specific to a service by setting appropriate isolation level.

You can set an isolation level by using the SET TRANSACTION ISOLATION LEVEL statement or system parameters provided by CUBRID. For details, see Concurrency/Lock Parameters.

The read operations that allow interference between transactions with isolation levels are as follows:

  • Dirty read : A transaction T2 can read D' before a transaction T1 updates data D to D' and commits it.
  • Non-repeatable read : A transaction T1 can read other value, if a transaction T2 updates data while data is retrieved in the transaction T2 multiple times.
  • Phantom read : A transaction T1 can read E, if a transaction T2 inserts new record E while data is retrieved in the transaction T1 multiple times.

The default value of CUBRID isolation level is REPEATABLE READ CLASS with READ UNCOMMITTED INSTANCES (3).

Isolation Levels Provided by CUBRID

CUBRID Isolation Level(isolation_level)

Other DBMS Isolation Level
(isolation_level)

DIRTY
READ

UNREPEATABLE
READ

PHANTOM
READ

Schema Changes of the
Table Being Retrieved

SERIALIZABLE (6)

SERIALIZABLE (4)

N

N

N

N

REPEATABLE READ CLASS with REPEATABLE READ INSTANCES (5)

REPEATABLE READ (3)

N

N

Y

N

REPEATABLE READ CLASS with READ COMMITTED INSTANCES (4)

READ COMMITTED (2)

N

Y

Y

N

REPEATABLE READ CLASS with READ UNCOMMITTED INSTANCES (3)

READ UNCOMMITTED (1)

Y

Y

Y

N

READ COMMITTED CLASS with READ COMMITTED INSTANCES (2)

 

N

Y

Y

Y

READ COMMITTED CLASS with READ UNCOMMITTED INSTANCES (1)

 

Y

Y

Y

Y