Synchronization conflict resolution

At times, changes that a client submits to the DB2 Everyplace Sync Server conflict with changes that other clients or applications previously made or are simultaneously making to the source tables. The Sync Server tracks the version of each record in each table in a replication subscription. Each client is similarly tracked to maintain a version of each record for each client's last synchronization with each table. This information allows the Sync Server to determine whether or not a client is attempting to update a row based on an obsolete version of the data for that row. If a client attempts to update a row based on an obsolete version of the data for that row, the update is rejected.

Conflict resolution happens when data is staged to the mirror tables on the mid-tier system, as shown in Figure 7. This occurs in the replication cycle following the client's synchronization session. As a result, conflicts from a client's updates will not be detected until after response messages are returned to the client during that synchronization. Rejections of client changes will be communicated back to the client in the first synchronization session following the replication in which the conflict was discovered. If a client change is based on an obsolete record, a correct version of that record will be returned in the original synchronization request.

Figure 7. How the Sync Server handles conflicts

Begin Figure 4. Two boxes of equal size; one on top of the other. The box on top represents Client 1. The box on the bottom represents box 2. These two boxes both point to a larger box representing a mid-tier system. The box representing Client 1 contains a VNMEDICALRECORD table. Under the box, it reads "last synchronization: 12:02:04". The box representing Client 2 contains a VNMEDICALRECORD table. Under the box, it reads "last synchronization: 12:02:45". The box representing Client 1 has an arrow pointing to the box representing the mid-tier system. On top of the arrow, it reads "update". Further along the arrow, it reads "rejected". The box representing Client 2 has an arrow pointing to the box representing the mid-tier system. On top of the arrow, it reads "update". The box representing the mid-tier system contains a M_VNURSE mirror database. The arrow from Client 2 reaches all the way across to the mirror database and creates a VNMEDICALRECORD mirror table. The arrow from Client 1 gets rejected before it reaches the mirror database. End Figure 4.

The client whose update was rejected receives both the rejected record and a correct version of that record. The rejected record is recorded in the log on the client or provided to the application by the client API. The correct version of that record replaces the original (rejected) record on the client's DB2 Everyplace database.

When DataPropagator applies the changed data from the mid-tier to the source database, additional types of conflicts can occur. See the DB2 Universal Database Replication Guide and Reference and the DB2 Universal Database Administration Guide for more information on how these conflicts are managed and resolved.

Related concepts

Related tasks