When a synchronization request occurs and the MobiLink server decides that a new connection must be created, the begin_connection event is fired and synchronization starts.
Following the synchronization, the connection is placed in a connection pool, and MobiLink again waits for a synchronization request. Before a connection is eventually dropped from the connection pool, the end_connection event is fired. But if another synchronization request for the same version is received, then MobiLink handles the next synchronization request on the same connection. There are a number of events that affect the current synchronization.
Within each synchronization, the following transactions may occur. Each transaction is optional.
You can specify multiple upload transactions with the dbmlsync -tu option.
In addition, you can have two connection transactions. A begin connection transaction occurs right after a connection is made, and an end connection transaction occurs when the connection is closed.
The primary phases of a synchronization are the upload and download transactions. The events contained in the upload and download transactions are outlined below.
The upload transaction applies changes uploaded from a remote database.
The begin_upload event marks the beginning of the upload transaction. The upload transaction is a two-part process. First, inserts and updates are uploaded for all remote tables, and second, deletes are uploaded for all remote tables.
The end_upload event marks the end of the upload transaction.
The download transaction fetches rows from the consolidated database. It begins with the begin_download event.
The download transaction is a two-part process. For each table, first deletes are downloaded, and then update/insert rows (upserts) are downloaded. The end_download event ends the download transaction.
The non-blocking download acknowledgement transaction is only performed when MobiLink is in non-blocking download acknowledgement mode and a download acknowledgement is received. This transaction has two purposes. The scripts publication_nonblocking_download_ack and nonblocking_download_ack are run in this transaction; they facilitate download status tracking. Secondly, download timestamps in the MobiLink system tables are updated during this transaction.
Note that this transaction is not performed on the same database connection as the other events for the target synchronization. This means that no connection level variables may be referenced in this transaction.
The following pseudocode provides an overview of the sequence in which events, and hence the scripts of the same names, are invoked. This representation of the MobiLink event model assumes a full synchronization (not upload-only or download-only) with no errors.
While each table can have its own table scripts, you can also write table-level scripts that are shared by several tables.
There should be no implicit or explicit commit or rollback in your SQL synchronization scripts or the procedures or triggers that are called from your SQL synchronization scripts. COMMIT or ROLLBACK statements within SQL scripts alter the transactional nature of the synchronization steps. If you use them, MobiLink cannot guarantee the integrity of your data in the event of a failure.
|Send feedback about this page via email or DocCommentXchange||Copyright © 2008, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.0|