IBM DB2 Everyplace Sync Server Administration Guide Version 7 Release 2 Modification 1


How synchronization happens

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.

From mobile to source

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



How changes a user submits for synchronization are applied to the source database

  1. A home health care specialist or visiting nurse updates the blood pressure of a patient in a local copy of the VNMEDICALRECORD table on a Palm OS device. The nurse exits the application used to edit the table, then taps the IBM Sync icon to start the synchronization client software on the device. When the synchronization client application starts, the nurse chooses the name of the application to synchronize, then taps Synchronize to request synchronization.
  2. The request is authenticated and then placed on an input queue on the mid-tier system. The synchronization client software on the device waits for a synchronization reply from the source server (see From source to mobile).
  3. Users can synchronize only the subset of data and files to which they have been subscribed.
  4. The data is placed into a staging table. Staging tables help improve throughput capacity of synchronization requests because changes can be staged while other updates are taking place.
  5. The data is copied from the staging table to the mirror table (VNMEDICALRECORD in this example) and potential update conflicts are resolved. Changes to the mirror table are recorded in the DB2 log.
  6. The DB2 DataPropagator Capture program starts. This program captures changes to the mirror table from the DB2 log and writes them to a change data (CD) table.
  7. The DB2 DataPropagator Apply program starts and applies changes from the CD table to the source table, VNMEDICALRECORD, in the VNURSE database on the source system.

From source to mobile

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



How changes to the source database are applied to the mobile database

  1. The DB2 DataPropagator Capture program, running continuously on the source system, captures changes to the VNMEDICALRECORD source table from the DB2 log and writes them to the CD table.
  2. The DB2 DataPropagator Apply program applies changes from the CD table to the mirror table, VNMEDICALRECORD. If update conflicts are identified they are resolved during this step of the process.
  3. The changes to data are sent to an output queue on the mid-tier system as a synchronization reply message.
  4. The synchronization client software retrieves the synchronization reply message from the output queue. The client retrieval request is authenticated.
  5. The changes to data are applied to the client's local copy of the table. The synchronization session ends.

Canceling a synchronization

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.

How conflicts are handled

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



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.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]