Overview of MobiLink events

When a synchronization request occurs and the MobiLink server decides that a new consolidated database connection must be created, the begin_connection event is fired and synchronization starts.

Flowchart of the MobiLink event model, showing the begin_connection event, a predefined process called do synchronizations, and an end_connection event.

Following the synchronization, the consolidated database connection is placed in a connection pool, and MobiLink again waits for a synchronization request. If another synchronization request for the same version is received, then MobiLink handles the next synchronization request on the same connection. Before a connection is eventually dropped from the connection pool, the end_connection event is fired.

There are many events in each synchronization. Most events are organized by the transaction containing them.

Transactions

Within each synchronization, the following transactions may occur.

authentication
begin synchronization
upload
prepare for download
download
end synchronization
non-blocking download acknowledgement

In addition, you can have two connection transactions. A begin connection transaction occurs right after a consolidated database 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

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.

Flowchart of the MobiLink upload transaction process.

The end_upload event marks the end of the upload transaction.

You can specify multiple upload transactions with the dbmlsync -tu option.

See Scripts to upload rows.

The download transaction

The non-blocking download acknowledgement transaction

The non-blocking download acknowledgement transaction is only performed when 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 help download status tracking. Secondly, download timestamps in the MobiLink system tables are updated during this transaction.

Note that this transaction may not be 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.

Event overview in pseudocode

Notes

Usually, if you have not defined a script for a given event, the default action is to do nothing.
The begin_connection and end_connection events are connection-level events. They are independent of any single synchronization and have no parameters.
Some events are invoked once per synchronization for each table being synchronized. Scripts associated with these events are called table-level scripts.

While each table can have its own table scripts, you can also write table-level scripts that are shared by several tables.
Some events, such as begin_synchronization, occur at both the connection level and the table level. You can supply both connection and table scripts for these events.
The COMMIT statements illustrate how the synchronization process is broken up into distinct transactions.

Caution

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.

MobiLink complete event model
Events during upload
Events during download

Discuss this page in DocCommentXchange.