OW2 Forge: Detail: 305363 Sync Time Differential Problem

Log In
New Account

Home

Tracker: Bugs

Submit New | Browse | Admin | ExportToXml

[ #305363 ] Sync Time Differential Problem

Date:
2006-05-25 20:52

Priority:
5

Submitted By:
Enno Derksen (ederksen)

Assigned To:
Nobody (None)

Category:
engine framework

State:
Open

Summary:
Sync Time Differential Problem

Detailed description:
The *Sync Time Differential Problem* occurs when using the Sync4J DS Server to synchronize with a server-side SyncSource that targets a database on another machine (i.e. other than the machine that runs the Sync4J DS Server). The following scenario assumes that the remote database server is one hour behind, e.g. when it is 14:00 on the Sync4J DS Server machine, it is 13:00 on the remote server. Note that both times are relative to the same timezone, it doesn't matter what the actual timezones on both machines are. * 14:00s means 14:00 according to the clock on the Sync4J DS Server * 13:00r means 13:00 according to the remote server, which is the same as 14:00s 1. 14:01s - Client does a Slow Sync and is now in sync. * Server Last Anchor is 14:01s (This is stored in the sync4j_last_sync table in the last_anchor_client column) 2. 13:05r - Change is made in the server-side database. Update timestamp is 13:05r 3. 14:08s - Client initiates Fast Sync. * Sync4J DS Server generates new anchor for server-side SyncSource approx. 14:08s * calls getUpdatedItems(since) where since=14:01s (i.e. using Last Server Anchor) * Server SyncSource does not return the modified item, which it thinks changed on 13:05r, which is before 14:01r * (Note that the SyncSource doesn't know about the time differential and assumes the 'since' value is relative to it's own clock, and therefore interprets 14:01 as 14:01r, where it should have been 13:01r) -------------------------------------------------------------------------------------------------------------------------- Proposed Solution: This problem could be easily avoided if it were left to the server-side SyncSource to generate the 'Next Server Anchor', rather than generating it in the Sync4J Server (i.e. in SyncSessionHandler.processMessage). A simple implementation change could be to let the beginSync() method in the server-side SyncSource API return this anchor value. (A SyncSource targeting a MySQL database could return "NOW()" via a JDBC query.) The Sync4JEngine.sync() method could store this anchor value in the db.serverAnchor.next property, so that SyncSessionHandler.commit() would write it into the database. On the next sync operation, the Sync4JEngine.sync() method will read it from the database and pass it via the since parameter of the prepareFastSync() method to the getNew/Updated/Deleted() methods of the appropriate SyncSource. -------------------------------------------------------------------------------------------------------------------------- * For (somewhat) backward compatibility, you could allow the beginSync() method to return null, in which case the engine would not override the db.serverAnchor.next property and default to the current behavior. That would work fine for datasources that run on the same machine as the Sync4J server. * Another change in this regard (which I remember seeing in the mailing list archive) is, that it would be nice if the last/previous anchor value (i.e. since) is passed when beginSync() is called, either as a parameter or as part of the Context in 3.0. See the following thread for additional thoughts from other users: http://sourceforge.net/mailarchive/forum.php?thread_id=10252286&forum_id=215

Add A Comment:

Please login

Followup

Message
Date: 2006-05-30 20:00 Sender: jfinkelstein
Date: 2006-05-29 14:53 Sender: stefano_fornari

Attached Files:

Name	Description	Download
No Files Currently Attached

Changes:

Field Old Value Date By

resolution_id None 2006-05-29 14:53 stefano_fornari