To resolve conflicting updates, Replication Server must maintain transaction commit order and resolve commit consistency deadlocks. Figure 4-7 describes the logic Replication Server uses to resolve conflicts using the rs_dsi_check_thread_lock function string.
Figure 4-7: Conflict resolution logic using the rs_dsi_check_thread_lock function string
The internal method assumes that Replication Server
detects and resolves conflicting updates 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, it could be holding resources required by an earlier transaction. 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 an earlier transaction:
If the thread is blocking another transaction (rs_dsi_check_thread_lock > 0), the current transaction rolls back, which resolves the 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.
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.
