Tickets :: Comment on [#12175] Add modification sequence support to Horde

* Your Email Address
* Spam protection	Enter the letters below: .__..__..__.. __ \| \|\| \|\| \|\| / ` \|__\\|__\\|__\\|___\__.
Comment	>> 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. >
Attachment
Watch this ticket

Saved Queries