Open Source RDBMS - Seamless, Scalable, Stable and Free

한국어 | Login |Register

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

Checking Lock Status


The cubrid lockdb utility is used to check the information on the lock being used by the current transaction in the database.


cubrid lockdb options database_name

options: [{-o|--output-file=} file ]

  • cubrid: An integrated utility for the CUBRID service and database management.
  • lockdb: A command used to check the information on the lock being used by the current transaction in the database.
  • options: The  -o option is supported.
  • database_name: The name of the database where lock information of the current transaction is to be checked.

Displaying lock information on a screen

The following example shows how to display lock information of the testdb database on a screen without any option.

cubrid lockdb testdb

Displaying lock information to the specified file (-o)

The following example shows how to display lock information of the testdb database as a output.txt by using the -o option.

cubrid lockdb -o output.txt testdb

Output Contents

The output contents of cubrid lockdb are divided into three logical sections:

•   Server lock settings

•   Clients that are accessing the database

•   The contents of an object lock table

Server lock settings

The first section of the output of cubrid lockdb is the database lock settings.

*** Lock Table Dump ***

 Lock Escalation at = 100000, Run Deadlock interval = 0

The lock escalation level is 100,000 records, and the interval to detect deadlock is set to 0 seconds (For a description of the related system parameters, lock_escalation and deadlock_detection_interval, see Concurrency/Lock-Related Parameters).

Clients that are accessing the database

The second section of the output of cubrid lockdb includes information on all clients that are connected to the database. This includes the transaction index, program name, user ID, host name, process ID, isolation level and lock timeout settings of each client.

Transaction (index 1, csql, dba@cubriddb|12854)


Timeout_period -1

Here, the transaction index is 1, the program name is csql, the user ID is dba, the host name is cubriddb, the client process identifier is 12854, the isolation level is READ COMMITTED CLASSES AND READ UNCOMMITTED INSTANCES, and the lock timeout is unlimited.

A client for which transaction index is 0 is the internal system transaction. It can obtain the lock at a specific time, such as the processing of a checkpoint by a database. In most cases, however, this transaction will not obtain any locks.

Because cubrid lockdb utility accesses the database to obtain the lock information, the cubrid lockdb is an independent client and will be output as such.

Object lock table

The third section of the output of the cubrid lockdb includes the contents of the object lock table. It shows which client has the lock for which object in which mode, and which client is waiting for which object in which mode. The first part of the result of the object lock table shows how many objects are locked.

Object lock Table:

    Current number of ojbects which are locked = 2001

cubrid lockdb outputs the OID, object type and table name of each object that obtained lock. In addition, it outputs the number of transactions that hold lock for the object (Num holders), the number of transactions (Num blocked-holders) that hold lock but are blocked since it could not convert the lock to the upper lock (e.g., conversion from U_LOCK to X_LOCK), and the number of different transactions that are waiting for the lock of the object (Num waiters). It also outputs the list of client transactions that hold lock, blocked client transactions and waiting client transactions.

The example below shows an object in which the object type is an instance of a class, or record that will be blocked, because the OID( 2| 50| 1) object that has S_LOCK for transaction 1 and S_LOCK for transaction 2 cannot be converted into X_LOCK. It also shows that transaction 3 is blocked because transaction 2 is waiting for X_LOCK even when transaction 3 is wating for S_LOCK.

OID = 2| 50| 1

Object type: instance of class ( 0| 62| 5) = athlete

Num holders = 1, Num blocked-holders= 1, Num waiters = 1


    Tran_index = 2, Granted_mode = S_LOCK, Count = 1


    Tran_index = 1, Granted_mode = U_LOCK, Count = 3

    Blocked_mode = X_LOCK

                    Start_waiting_at = Fri May 3 14:44:31 2002

                    Wait_for _nsecs = -1


    Tran_index = 3, Blocked_mode = S_LOCK

                    Start_waiting_at = Fri May 3 14:45:14 2002

                    Wait_for_nsecs = -1

It outputs the lock information on the index of the table when the object type is the Index key of class (index key).

OID = -662|   572|-32512

Object type: Index key of class ( 0|   319|  10) = athlete.

Index name: pk_athlete_code

Total mode of holders =   NX_LOCK, Total mode of waiters = NULL_LOCK.

Num holders=  1, Num blocked-holders=  0, Num waiters=  0


    Tran_index =   1, Granted_mode =  NX_LOCK, Count =   1

Granted_mode refers to the mode of the obtained lock, and Blocked_mode refers to the mode of the blocked lock. Starting_waiting_at refers to the time at which the lock was requested, and Wait_for_nsecs refers to the waiting time of the lock. The value of Wait_for_nsecs is determined by lock_timeout_in_secs, a system parameter.

When the object type is a class (table), Nsubgranules is displayed, which is the sum of the record locks and the key locks obtained by a specific transaction in the table.

OID = 0| 62| 5

Object type: Class = athlete

Num holders = 2, Num blocked-holders= 0, Num waiters= 0


Tran_index = 3, Granted_mode = IS_LOCK, Count = 2, Nsubgranules = 0

Tran_index = 1, Granted_mode = IX_LOCK, Count = 3, Nsubgranules = 1

Tran_index = 2, Granted_mode = IS_LOCK, Count = 2, Nsubgranules = 1