Understanding K-DB Lock Structure and Operation Mechanisms

K-DB Lock Information

In a clustered K-DB database each lock records a set of fields that allow the system to manage concurrency and recovery.

DataBlock address – physical address of the data block being locked.

Instance id – identifier of the node (instance) that holds the lock.

Lock mode – S (shared) for read, X (exclusive) for write.

Block state – current state of the block, e.g. SCUR, XUR, and the special PAST IMAGE (PI) state used when a modified block is propagated to other nodes for fast recovery.

Role – consistency scope: local when at most one node differs from the disk version, global when two or more nodes are out‑of‑sync, which determines the write‑back procedure.

Lock Lifecycle

The lock lifecycle consists of three phases:

Acquisition – the most complex phase; the requesting instance contacts the master node, which consults the Cluster Wait‑Lock Service (CWLS) to determine compatibility with existing locks.

Usage – the lock protects the data block while the instance performs read or write operations.

Release – the lock is removed from the granted list and any waiting conversions are re‑evaluated.

Cluster Wait‑Lock Service (CWLS)

CWLS is the core lock‑management component. For each data block it maintains two queues:

Granted queue – locks whose modes are mutually compatible and can be granted immediately.

Conversion queue – lock requests that are incompatible with the current granted set; they wait until the existing locks are downgraded or released.

Example scenario:

Node A and Node B both request a shared ( S) lock on block X. Because S ‑locks are compatible, both entries are placed in the granted queue.

Node C subsequently requests an exclusive ( X) lock on the same block. CWLS detects the incompatibility, moves Node C’s request to the conversion queue, and sends a downgrade request to the holders of the shared locks.

When either Node A or Node B releases or downgrades its lock, CWLS re‑evaluates the conversion queue and may grant the exclusive lock to Node C.

Key Concepts

PAST IMAGE (PI) state – a block that has been modified on one node and propagated to others retains a PI copy of the latest version. This enables rapid recovery when a node fails.

Local vs. Global role – a local role indicates that only one node’s cache differs from the on‑disk version; a global role indicates multiple divergent caches, requiring coordinated write‑back.