Mobile Transaction Management in DB2 Everyplace

[Former Member]

General information of DB2 Everyplace

DB2 Everyplace is an off-line single-user relational database with a footprint of 180 KB that provides local store on mobile devices. It is available for Palm OS, Symbian OS, Windows CE, Windows 95/98/NT/2000/XP, Linux, and embedded Linux devices. DB2 Everyplace supports a subset of SQL and provides indexing. It contains a bi-directional Synchronization Server that synchronizes relational data between the mobile device and enterprise data sources (DB2, Oracle, Informix, Sybase, MS SQL Server and Lotus Domino). DB2 Everyplace provides flat transaction management (commit, auto-commit and rollback operations). In connected mode mobile devices may request queries and stored procedures executions on the database server.

Synchronization process

The synchronization between the mobile database and the backend database is performed in a mid-tier system. On the backend system, the DB2 DataPropagator Capture program, running continuously on the source database, captures changes that have been subscribed by users and writes them to a change data (CD) table. Then, the DB2 DataPropagator Apply program applies changes from the CD table to the mirror table located on the mid-tier system. The changes to data are sent to an output queue on the mid-tier system, waiting for the next synchronization triggered from the client side. On a mobile client, the synchronization is triggered manually by the user. Then, updates performed on the mobile database are sent to the mid-tier system and are placed into a staging table. Then, the synchronization client software retrieves the synchronization reply message from the output queue that contains the server side changes since the last synchronization.  Finally, the changes to data are applied to the clients local copy of the table. The synchronization session ends and the mobile client can disconnect with the server.

Uploading client updates and validation

AS the Oracle solution, client side updates are processed separately from the synchronization. The data is copied from the staging table to the mirror table. Potential update conflicts are detected at this moment by validating the version number of each data item. If a client side update is based on an obsolete version of a data item, the update is rejected. Validated changes are stored in the mirror table. The DB2 DataPropagtor Capture program captures changes to the mirror table and writes them to the CD table. The DB2 DataPropagator Apply program eventually applies changes from the CD to the backend database. Rejections of updates will be communicated back the MC in the first synchronization session following the validation process. If a client change is based on an obsolete record, a correct version of that record will be returned.

 

The DB2 solution uses staging tables to improve throughput capacity of synchronization requests because changes can be staged while other updates are taking place. As the Oracle solution, it also uses the asynchronous approach to process client side updates to reduce the communication cost and hence has the same problem that the notification of an abort to the user might take a long time.