The synchronization process can be one- or two-way. This section covers two-way synchronization. The two-way synchronization process has two steps:
This two-step process is known as a synchronization session.
Figure 2 shows how changes that a user submits are applied to the source database during synchronization. The numbers in the figure correspond to the explanation following it:
Figure 2. How changes that a user submits for synchronization are applied to the source database
![]() |
Figure 3 shows how changes from a source table are applied to a DB2 Everyplace table on the user's mobile device during synchronization. The Sync Server sends to the user all relevant source data changes that have been made since the user's last synchronization. The Sync Server sends only changed data that the user is subscribed to.
The numbers in the figure correspond to the explanations following it.
Figure 3. How changes to the source database are applied to the mobile database
![]() |
A synchronization can consist of several synchronization sessions. If you cancel the synchronization process and restart it later, the Sync Server attempts to resume from the first synchronization session that was not completed, rather than starting over.
For example, suppose you requested synchronization of 100 records for one subscription and 50 for another subscription. If the 100 records of the first subscription had been synchronized completely at the time you canceled, the remaining 50 records will only be synchronized when you re-initiate the synchronization. This is because only the first synchronization session had been completed.
If the user cancels synchronization during a synchronization session, no records in that particular session are synchronized. If the user successfully sends all changed records from the device to the server but cancels during the server's reply, the server will resume the reply when the user reconnects to the Sync Server.
At times, changes that a client submits to the DB2 Everyplace Sync Server conflict with changes that other clients 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 4. This occurs during the next replication cycle. Conflicts that result from a client's updates will not be detected until after response messages are returned to the client during that synchronization. Any rejections of client changes will not be communicated back to the client until the next synchronization. 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 4. How the Sync Server handles conflicts
![]() |
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. 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.