How does Cubrid handle Database concurency?

Like other database management systems CUBRID supports the concept of transactions. Concurrency occurs when two transactions are executed simultaneosly. The goal is usually to make sure that the data modification operations performed in one of the transactions affect the operations being done in the second transaction as little as possible. In order to achieve this goal database management system sets locks on the resources (records or even whole tables) being accessed inside transactions. The strategy of setting these locks is based on transaction isolation level. The rule of a thumb is the higher the isolation level the more independent the results of concurrent transactions are. The lower the isolation level the more transactions can be executed concurrently.

CUBRID supports a number of transaction isolation levels like SERIALIZABLE, REPEATABLE READ CLASS with REPEATABLE READ INSTANCES, REPEATABLE READ CLASS with READ COMMITTED INSTANCES, REPEATABLE READ CLASS with READ UNCOMMITTED INSTANCES, READ COMMITTED CLASS with READ COMMITTED INSTANCES and READ COMMITTED CLASS with READ UNCOMMITTED INSTANCES.

You can read more about transaction isolation level in CUBRID here.