detail.php
OW2 Forge: Detail: 305363 Sync Time Differential Problem

Advanced - Powered by Google


   
Log In
New Account
  
 
Home
My Page
Project Tree
Project Openings
Funambol
          
 
 
Summary
Tracker
Lists
Tasks
Docs
News
CVS
Files
                
 

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
Logged In: YES 
user_id=8085

1 point awarded and added to BaB tally on May 30
Date: 2006-05-29 14:53
Sender: stefano_fornari
Logged In: YES 
user_id=1039

This is actually not a bug but a limitation of the product.
I filed a RFE for it:
http://forge.objectweb.org/tracker/index.php?func=detail&aid=
305388&group_id=96&atid=350096

However, I would make it eligible for BaB anyway.

Attached Files:

Name Description Download
No Files Currently Attached

Changes:

Resource id #66listtable
resolution_id
Field Old Value Date By
resolution_idNone2006-05-29 14:53stefano_fornari

Copyright © 1999-2008, OW2 Consortium | contact | You have a difficulty, a problem ? Please report an issue using your OW2 forge account credentials