MobiLink Synchronization User's Guide
Server-Initiated Synchronization
This section describes a hypothetical set of operations. It illustrates how server-initiated synchronization helps remote and consolidated databases stay in sync.
The walkthrough describes a situation with two remote databases (A and B). The following configuration parameters are set at the consolidated database:
the Notifier polling interval is 2 minutes
each push request has a resend interval of 5 minutes
each push request has a time-to-live period of 6 minutes
The walkthrough starts just before noon on a business day. Initially, the remote databases A and B are both fully synchronized with the consolidated database. Here is a possible sequence of events.
On Remote A the Listener is on, but on Remote B the Listener is off.
Data is changed on the consolidated database.
The Notifier polls at 12:00:
The begin_poll statement is executed, and inserts push requests for A and B into the PushRequest table.
The request_cursor SELECT statement is executed to query the PushRequest table.
The Notifier sends messages to both remotes.
The Listener on Remote A picks up the message and invokes synchronization.
The synchronization resets the status of the push request and updates the last_sync_time for Remote A.
Being offline, Remote B does not receive the message and is not synchronized.
The next Notifier poll is two minutes later, at 12:02:
The begin_poll statement is executed. This won't insert a request for Remote A because its last_sync_time is greater than the last_modified time of the Dealer data. This won't insert a request for Remote B because the request has already been sent.
The request_cursor statement is executed to query the PushRequest table. The handled request for Remote A is not in the result set because the last_sync_time is greater than the req_time (but it is still in the PushRequest table). The request for Remote B remains in the result set.
The request_delete statement is executed. This performs automatic cleanup of the request for Remote A because it is implicitly dropped.
The Notifier does not send a message to Remote B because the resend time is 12:05. The request for Remote B is pending for resend.
The next Notifier poll is at 12:04:
The begin_poll statement is executed. This won't insert a request for Remote A because its last_sync_time is greater than the last_modified time of the Dealer data. This won't insert a request for Remote B because the request has already been inserted.
The request_cursor statement is executed to query the Request table. The request for Remote B remains in the result set.
The Notifier does not send a message to Remote B because the resend time is 12:05. The request for Remote B is pending for resend.
The next Notifier poll is at 12:05:
The begin_poll statement is executed. This won't insert a request for Remote A because its last_sync_time is greater than the last_modified time of the Dealer data. This won't insert a request for Remote B because the request has already been inserted.
The request_cursor statement is executed to query the Request table. The request for Remote B remains in the result set.
The Notifier sends the message to Remote B again.
The next Notifier poll is at 12:07:
The begin_poll statement is executed. This won't insert a request for Remote A because its last_sync_time is greater than the last_modified time of the Dealer data. This won't insert a request for Remote B because the request has already been inserted.
The request_cursor statement is executed to query the Request table. The request for Remote B remains in the result set.
The request_delete statement is executed. This performs automatic cleanup of the request for Remote B because it has exceeded its time to live.
There are no pending requests.
The next Notifier poll is at 12:09...