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
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.
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. 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.
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.
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. |
Replication 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.
