OceanBase Database maintains the waiting relationships between locks in memory. When a lock is released, it wakes up the transactions waiting on the lock.
Lock Wait Mgr (Lock Wait Manager) maintains the waiting relationships between rows and transactions in memory and wakes up the waiting transactions for retry when a lock is released. The wake-up operation may be triggered by transaction termination, SAVEPOINT rollback, or early unlock.
Types of lock waiting relationships
In Lock Wait Mgr, there are three types of lock waiting relationships: row lock, table lock, and transaction.
Row lock waiting relationship
A row lock waiting relationship is a regular data waiting relationship. When a row lock is released, the system wakes up the first transaction in the waiting queue for retry.
Table lock waiting relationship
A table lock waiting relationship is similar to a row lock waiting relationship, but the conflict is based on table-level locking. A table lock affects all operations on the table.
Transaction waiting relationship
To reduce memory usage, row lock waiting relationships are converted to transaction waiting relationships in scenarios such as dump. When a transaction ends, the system wakes up all other transactions waiting on the transaction for retry.
Establishment of lock waiting relationships
Local establishment
Take a row lock as an example. When different transactions acquire locks on the same row, they collect conflict information, such as the lock acquisition time, row hash, lock holder transaction ID, and lock acquisition transaction ID. They also record the seq value of the corresponding Lock Wait Mgr bucket at this time. This seq value corresponds to the bucket and increments by 1 when the hash value mapped to this bucket is released. After a lock acquisition fails, the transaction rolls back the statement and enters the corresponding bucket to wait for the lock. Before entering the bucket, it compares the recorded seq value with the current seq value of the bucket to determine if a lock has been released. If the seq value has changed, the transaction immediately retries the request without entering the waiting queue. Otherwise, it enters the queue to wait for the lock.
Remote establishment
For remote execution, the establishment of waiting relationships is more complex. During remote execution, conflict information is also collected and sent back to the control node. At the control node, the corresponding Lock Wait Mgr bucket is entered for waiting. Since the waiting row is not on this node, the execution node also enters the Lock Wait Mgr bucket for waiting. The purpose is to detect and remotely notify the control node for retry when the lock is released. That is, when the lock is released, the waiting node in the execution node's queue remotely wakes up the control node for retry. To prevent the loss of remote wake-up operations due to network issues or node failures, a periodic probing mechanism is also in place. The waiting transaction at the control node periodically probes the status of the execution node. If an abnormality is detected, it directly removes the request from the queue for retry.
Maintenance of lock waiting relationships
In fact, Lock Wait Mgr maintains a HashMap with a fixed number of buckets. Based on the hash mapping result, the waiting transactions are linked as a linked list to the corresponding bucket. When a lock is released, the system simply removes the corresponding transaction from the hash bucket for retry.