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-9 describes the logic Replication Server uses to resolve commit order deadlocks using the rs_dsi_check_thread_lock function string.

Figure 4-9: 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.

NoteThe 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-9. 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:


Function strings for internal commit control

Replication Server uses the rs_dsi_check_thread_lock function to check whether the current DSI executor thread is blocking another replicate database process. This function has function-string-class scope. It is called only if the DSI executor thread is ready to commit but cannot because it is not next to commit, and the amount of time specified for dsi_commit_check_locks_intrvl has elapsed. If commit order contention occurs frequently, consider decreasing the wait time specified by dsi_commit_check_locks_intrvl.

Table 4-7: System functions that support internal commit control

Function

Description

rs_dsi_check_thread_lock

Determines whether or not the DSI executor thread is holding a lock that blocks a replicate database process. A return value greater than 0 indicates that the thread is holding resources required by another database process, and that the thread should roll back and retry the transaction.

NoteReplication Server automatically creates function strings for the above function in function-string classes in which Replication Server generates default function strings. For other function-string classes, you must create these function strings before you can use parallel DSI features with dsi_commit_control set on.