Learn how Replication Server resolves commit order deadlocks in Replication Server using the rs_dsi_check_thread_lock function string.
To preserve transactional integrity, Replication Server must maintain transaction commit order and resolve commit order consistency deadlocks.
This figure describes the logic Replication Server uses to resolve commit order deadlocks.
Replication Server reads the commit information sent from the primary database and uses this information to define and maintain the transaction commit order at the replicate database.
If a DSI executor thread’s transaction processing is complete and it is expected to be the “next” transaction to commit, it is allowed to do so. If a thread’s transaction processing is complete and it is not the “next” transaction expected to commit, the thread must await its turn to commit.
If a thread’s transaction processing is complete and it is not the next transaction expected to commit, the transaction could be holding resources required by a transaction scheduled to commit earlier. After waiting the amount of time specified in the dsi_commit_check_locks_intrvl parameter, a DSI executor thread executes the rs_dsi_commit_check_thread_lock function string to determine if the thread holds a lock on resources needed by the earlier transaction:
If the thread is blocking another transaction (rs_dsi_check_thread_lock > 0), the current transaction rolls back, which resolves the commit order deadlock and allows the earlier transaction to commit. Only the blocking transaction rolls back; other transactions process normally.
If the thread has not executed rs_dsi_check_thread_lock more times than is defined in dsi_commit_check_locks_max, the transaction commits if it is next, or it waits again the amount of time specified in dsi_commit_check_locks_intrvl.
If the thread has executed rs_dsi_check_thread_lock more times than is defined in dsi_commit_check_locks_max, the current transaction rolls back.