Parallel DSI processing must duplicate the commit order of transactions at the primary database yet allow transaction updates to process simultaneously. It must then resolve any transaction contentions that occur as a result. Critical transaction contentions—or contention deadlocks—can occur when a transaction cannot commit because it must wait for an earlier transaction to commit, and the earlier transaction cannot commit because needed resources are locked by the later transaction.
For example, DSI threads A and B are processing transactions in parallel. Thread A’s transaction must commit before thread B’s transaction. Thread B’s transaction locks resources needed by thread A. Thread B’s transaction cannot commit until thread A’s transaction commits, and thread A’s transaction cannot commit because needed resources are locked by thread B.
Replication Server provides two methods for resolving deadlocks:
Internally, using Replication Server internal tables and function strings, or
Externally, using the rs_threads system table in the replicate database.
The internal method is handled primarily within Replication Server, and uses the rs_dsi_check_thread_lock function string for deadlock detection. The external method requires both Replication Server and the replicate database, and uses the rs_threads system table for both commit order validation and deadlock detection.
Sybase recommends the internal method, which is the default, for both Sybase and non-Sybase data servers. This method requires less network I/O than the external method, and, if a deadlock occurs, may require the rollback of only a single transaction. The external method requires more network I/O and results in the rollback of several transactions. The external method is included for compatibility with previous versions of Replication Server.
If Replication Server encounters commit contention and dsi_commit_control is “on,” Replication Server rolls back and retries one transaction. If, however, Replication Server encounters transaction contention and dsi_commit_control is “on,” Replication rolls back retries all transactions serially. If dsi_commit_control is “off,” Replication Server rolls back and retries all transactions serially for either type of contention.
To select a method, enter the alter connection command with the dsi_commit_control option. For example, to choose the internal method for the pubs2 database on the TOKYO_DS data server, enter:
alter connection to TOKYO_DS.pubs2 set dsi_commit_control to ‘on’
Setting dsi_commit_control to “on” specifies the internal method; setting dsi_commit_control to “off” specifies the external method.
