OceanBase Database maintains waiting relationships between locks in the memory. When a lock is released, OceanBase Database wakes up other transactions waiting for the lock.
Lock Wait Mgr maintains the waiting relationships between rows and transactions in memory, and wakes up waiting transactions to retry once the lock is released. Wake-up operations can be triggered by events such as transaction completion, savepoint rollback, or early unlocking.
Types of lock wait relationships
Lock Wait Mgr maintains three types of lock wait relationships: row lock wait, table lock wait, and transaction wait.
Row lock wait relationships
Row lock wait relationships are regular data wait relationships. When a row lock is released, the system wakes up the first transaction in the wait queue to retry.
Table lock wait relationships
Table lock wait relationships are similar to row lock wait relationships, except that conflicts in table lock wait relationships are implemented based on locking at the table level. A table lock affects all operations on the table.
Transaction wait relationships
To reduce memory usage, row lock wait relationships are converted into transaction wait relationships in scenarios such as minor compactions. When a transaction ends, the system wakes up all transactions waiting for it.
Establish lock wait relationships
Establish lock wait relationships locally
Here we use a row lock as an example. If mutual exclusion occurs when different transactions lock the same row, the system collects the conflict information, such as lock time, hash value of the locked row, ID of the transaction holding the row lock, and IDs of the transactions trying to lock the row. In addition, the system records the seq value of the Lock Wait Mgr bucket corresponding to the hash value. Each seq value is mapped to a specific bucket. Once the lock holder releases the lock, the seq value increases by one. If a transaction fails to acquire the lock, it first rolls back the statement and then compares the recorded seq value with the current seq value of the bucket to check whether the lock has been released. If the two values differ, the transaction retries the request without entering the lock wait queue. Otherwise, the transaction enters the queue to wait for the lock.
Establish lock wait relationships remotely
It is more complex to establish wait relationships for remote execution. During remote execution, the system also collects conflict information and sends it back to the control OBServer node. As the locked row does not reside on the control OBServer node, the transaction enters the Lock Wait Mgr bucket on both the control OBServer node and the execution OBServer node to wait. This enables the waiting execution OBServer node to remotely notify the control OBServer node of lock release and wake it up for a retry. To prevent the loss of remote wake-up operations due to anomalies such as network issues and crashes, a periodic detection mechanism is implemented. A transaction waiting on the control OBServer node periodically checks the status of the execution OBServer node. If an anomaly is detected, the system directly removes the transaction from the queue and retries the request.
Maintain lock wait relationships
Lock Wait Mgr maintains a HashMap with a fixed number of buckets and puts transactions waiting for a lock in a bucket in the form of a linked list based on the hash mapping results. When waking up a transaction, Lock Wait Mgr removes the transaction from the corresponding bucket and retries the transaction.