Learn how Replication Server resolves commit order deadlocks externally using the rs_threads table.
The rs_threads table is located in the replicate database. It contains a row for each DSI executor thread. To simulate row-level locking, it has two columns, id and seq, and enough dummy columns so that only one row fits on a page. The id column is used as a unique clustered index.
At the beginning of a transaction, the DSI executor thread updates its row in the rs_threads table with the next available sequence number. When it is ready to commit the transaction, the thread sends a select statement to the replicate data server to select, from the rs_threads table, the sequence number of the transaction that should have committed prior to the transaction.
Because the preceding transaction holds a lock on this row in rs_threads, this thread is blocked until the preceding transaction commits.
If the sequence number that is returned is less than the expected value, the thread determines whether it should roll back the transaction or retry the select operation. Because the DSI formats many commands into a single batch before submitting it to the Adaptive Server, a thread may be ready to commit before the preceding transaction has submitted any commands to the Adaptive Server. In this case, the select in the rs_threads table may be submitted several times.
If the sequence number that is returned matches the expected value, the transaction can commit.