[Tickets #12175] Re: ActiveSync misses changes from history database

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12175
------------------------------------------------------------------------------
  Ticket             | 12175
  Updated By         | Thomas Jarosch <thomas.jarosch at intra2net.com>
  Summary            | ActiveSync misses changes from history database
  Queue              | Synchronization
  Version            | Git master
  Type               | Bug
  State              | Assigned
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Thomas Jarosch <thomas.jarosch at intra2net.com> (2013-04-12 08:06) wrote:

> Nevermind. I guess the swapping server wouldn't be answering the  
> query requests until it's done swapping and the pending writes are  
> committed anyway.

A swapping server is just a specialization of a multitasking  
environment in this case, so let's focus on that :)

Your assumption about the problem is correct. Think about how the  
history backend works: If no timestamp is given to log(), it will use  
the current time as timestamp.
In the worst case the time span between the time() call and the actual  
INSERT/UPDATE query might take a few seconds to ages.

The Horde_History::log() function works like this (simplified):
- get the complete history for $guid
- set ts to time() if no timestamp is given
- issue an UPDATE sql statement if replaceAction=true
   for every matching row from the previously retrieved entries

   OR:
   INSERT new entry into the database


The OS might interrupt / slow down the execution of the script  
updating the history and let another process instance (the ActiveSync  
server) execute first / faster. Increasing the fudge factor will only  
hide the problem and will break sooner or later.

The history backend needs a monotonic counter in addition to the  
timestamp. The timestamps are good for filtering on "give me all  
calendar entries changed in the last two weeks" but are not reliable  
for synchronization.

The monotonic counter needs to increase on every history database  
modification. We then save the last seen counter value in the  
"ActiveSync sync state" and can use this to look up new changes.

I'll have a look at the APIs involved and try to come up with a BC way  
to modify the API.