Tickets :: Comment on [#12567] AS: Unlikely race condition leads to data loss

Search Results: 77 of 247 [ <<First <Prev Next> Last>> ] [ Return to Search Results ]

* Your Email Address
* Spam protection	Enter the letters below: ._.._..___.. .. . \| \| \| \| \|\| \| _\|__\|_ \| \|__\|\|__\|
Comment	> Hi, > > after intensive torture testing the ActiveSync code and day-long > email exchange with Michael ([mjr]) (thanks for your help!) > I figured out this scenario were the current sync engine > might skip a change on the server: > > ---------------------------------------------------------------- > (1) Client sends a SYNC request to the server. > It notes 10 as the last used modseq in the syncState. > > (2) Client sends a change to the server. We import the change > via _as->driver->ChangeMessage(). Internally that function > is split into non-atomic parts (2a) and (2b). > > (2a) We store the change via the API into the backend. > The modseq stored in the history table is 13. > > (x) Someone else does a change to the same object. > The modseq stored in the history table is 16. > > (2b) ChangeMessage() finally calls smartStatMessage() on "our" > change from (2a). We will return 16 as the modseq. > > (3) We insert the sync_key, the returned modseq and the object_uid > into the syncMap. > This will insert the modseq 16 into the syncMap. > > (4) The client sends his SYNC request. > The last sync request was at 10, so it will grab > all changes between 10 and 16. > > (5) The server part sees the MODIFY change for the object_uid sent in (2) > It will call $backend->statMessage() and return 16 for this message. > getPIMChangeTS(object_uid) will also return 16. > > As $pim_ts(=16) is >= $stat['mod'](=16) we ignore the > change as originating from the PIM even though another > user changed the object. > ---------------------------------------------------------------- > > The root issue here is that the API and the horde apps don't > transport the modseq value after doing a change in Horde_History. > > Transporting this value back to the ActiveSync layer is complex > surgery and not doable in a BC way. We needed to come up with another > solution. > I'll add the proposed solution in a separate message. > > Thomas >
Attachment
Watch this ticket

Saved Queries