Replication Server depends on data servers to provide transaction-processing services. To guarantee the integrity of distributed data, data servers must comply with transaction-processing conventions, such as atomicity and consistency.
Data servers that store primary data provide most of the concurrency control needed for the distributed database system. If a transaction fails to update a table with primary data, Replication Server does not distribute the transaction to other sites. When a transaction does update primary data, Replication Server distributes the changes and, unless a failure occurs, the update succeeds at all sites that have subscribed to the data.
Promotes high availability of data because it does not lock the data for the duration of the distributed transaction. Instead it rolls back changes in the event of a conflict.
Requires fewer system resources to process a transaction.
Does not require data servers to have special distributed transaction processing features in order to participate in a distributed transaction.
A modification to primary data may fail to update a replicate copy of the data at another site.
The data server’s maintenance user login name does not have the permissions needed to update the replicate data.
The replicate and primary versions of the data are inconsistent after a system recovery.
A client updates replicate data directly rather than updating the primary version.
The data server storing the replicate table has constraints that are not enforced by the data server storing the primary version.
The data server storing the replicated copy of the table rejects the transaction due to a system failure, such as lack of space in the database.
When a transaction fails, Replication Server receives an error from the data server. Data server errors are mapped to Replication Server error actions. The default action for a failed transaction is to write a message in the Replication Server error log (including the message returned by the data server) and then suspend the database connection. After you correct the cause of the failure, you can resume the database connection and Replication Server will retry the failed transaction.
You also can have Replication Server record a failed transaction in the exceptions log (a set of three tables in the Replication Server System Database) and continue processing the next transaction. See Replication Server for a description of the RSSD.
If you use the exceptions log, you must manually resolve the transactions that are saved there to make the replicate data consistent with the primary data. In some cases, the process can be automatic by encapsulating the logic for handling the rejected transactions in an intelligent application program.
A transaction that modifies primary data in more than one data server may require additional concurrency control. According to the transaction processing requirements, either all of the operations in the transaction are performed or none of them are performed. If a transaction fails on one data server, it must be rolled back on all other data servers updated in the transaction.
Normally, there is exactly one Replication Agent for each primary database. If a single transaction updates multiple primary databases, that transaction is replicated as multiple independent transactions, one for each primary database. Or, you can select to encapsulate such transactions in a single stored procedure, which then flows as an atomic unit to subscribing sites.