AnsweredAssumed Answered

Off line sync - transactional: all timestamps the same after commit?

Question asked by justinc on Oct 12, 2015
Latest reply on Oct 13, 2015 by justinc

I'm having an issue with and offline sync setup that I created.  I used the basic outline as described in the FM white paper for offline syncing.  I'm using a transactional model for the whole sync process, so there is a final commit at the end if things don't throw an error.

 

The FM white paper talks about using a 'modification_TS' override field in order to maintain the proper time stamps on records when they are created on the other side.  So I have two mod_TS fields:  1 is a standard 'last record modification TS' called "zModTS_Always", and the other is "ModTS_Useful" field that is supposed to reflect the timestamp the record was modified by the user, and not the one where it was modified by the sync process.  It is defined thusly: 

        If( zModTS_Always and Sync::ModOverride_g ; Sync::ModOverride_g ; zModTS_Always )

 

So if the override field is defined (which only happens during the sync process), it will use that override TS as the entry for the ModTS_Useful, otherwise it uses the regular zModTS_Always field (the 'Always' one) as the timestamp.  This is important because you don't want the modification time to be changing whenever someone syncs - this would cause all kinds of re-syncing between users.

 

My problem is that the final commit at the end of the sync process is causing all the records that were just sync'ed to have a timestamp equal to the 'useful' time stamp of the last record sync'ed.  It isn't the timestamp at the point of the sync itself, the override field is still functioning as expected.

 

Here's an example: say I sync 3 records at 22:43.  During the sync process the modification time stamps for these 3 new records, reflected at the destination, are:

1:  15:00

2:  13:24

3:  18:31

 

That's as it should be.  But then at the end of the process, when the final commit happens, the three records change:

1:  18:31

2:  18:31

3:  18:31

 

This might not be too much of a problem...at least the times are something prior to the sync time.  But I am sorting a portal of these records based on this timestamp, and having them all with the same timestamp makes the sort rather useless.  Or if I were to commit each record after it was created, that would probably solve the problem - but that eliminates the transactional benefits.

 

Anyone familiar with maintaining modification timestamps using a transactional technique?

 

Thanks,

Justin

Outcomes