[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              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Thomas Jarosch <thomas.jarosch at intra2net.com> (2013-04-11 14:47) wrote:

> The other possibility would be to somehow track the most recent  
> history id detected. Though I really don't like this approach since  
> it means the client code would need knowledge of how they history  
> system functions - and it assumes any history backend would both  
> have some unique entry identifier, and those identifiers are numeric  
> (or at least increase in some numeric-like fashion).

My idea of abusing the history_id as monotonic counter is doomed anway:
In the Kolab world, an object can disappear and re-appear. So a  
history database entry with a low id might have a current timestamp  
and therefore be missed again.

> Both approaches would require some API changes to both the  
> activesync code as well as the history code in order to provide the  
> needed data - and such changes would need to maintain BC.

It seems like a good idea to keep an array of seen object UIDs during  
the last sync timestamp window (start_ts <= x <= end_ts). We would  
also need to keep this list for every action (add, modify, delete).

We can start expiring entries in this list once the current "start_ts"  
is higher than the last noted end_ts.

That still leaves one problem: If an object gets changed twice during  
the same second and a client already saw the first change, it will  
miss the second change. This risk is rather low but it will happen  
sooner or later.

Only a monotonic counter will solve this. Let's see if we can come up  
with a simpler solution...