Resolving conflicts internally 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. Figure 4-8 describes the logic Replication Server uses to resolve commit order deadlocks using the rs_dsi_check_thread_lock function string.

Figure 4-8: Conflict resolution logic using the rs_dsi_check_thread_lock function string

Figure 4-8 describes the logic Replication Server uses to resolve commit order deadlocks using the R S underscore D S I underscore check underscore thread underscore lock function string. From the primary data server, transactions are processed in the Replication Server. If the transaction being processed is the next one to commit, the Replication Server performs commit, otherwise the Replication Server will check if the D S I underscore commit underscore check underscore locks underscore I N T R V L time has elapsed. If it has elapsed, Replication Server checks if R S underscore D S I underscore check underscore thread underscore lock is greater than zero, otherwise it will wait and then goes back to checking if transaction is to commit. If R S underscore D S I underscore check underscore thread underscore lock is greater than zero, transactions are rolled back, processed, and checked again if to commit, otherwise, Replication Server checks if D S I underscore commit underscore check underscore locks underscore max has been reached. If yes, transactions are rolled back, processed, and checked if to commit, otherwise it will wait and then goes back to checking if transaction is to commit.

The internal method resolves commit order deadlocks that Replication Server detects and resolves conflicting updates only within Replication Server. If a deadlock is detected by the replicate database, the replicate chooses a transaction to roll back. To guarantee commit order, Replication Server must roll back all transactions currently executing against the replicate database. Replication Server then reapplies the transactions serially.

Maintaining commit order

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.

Resolving commit consistency deadlocks

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. See Figure 4-8. 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 is not blocking another transaction, it checks to see if it has executed rs_dsi_check_thread_lock more times than is defined by the dsi_commit_check_locks_max parameter.
- 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.