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

[noreply at bugs.horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/12567
------------------------------------------------------------------------------
  Ticket             | 12567
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | AS: Unlikely race condition leads to data loss
  Queue              | Synchronization
  Version            | Git master
  Type               | Bug
-State              | Assigned
+State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2013-11-20 18:22) wrote:

Looking at this again.

The strategy of using an MD5 of the object won't work. When sending  
changes from client->server, we are not guaranteed to have the full  
object represented. Often times the client will only send the changed  
properties, so we would need to first apply the change to the backend,  
then fetch the change again before calculating the MD5. Of course,  
this also opens up another place we could run into the race condition  
we are trying to prevent. I.e., someone else could modify the object  
between our committing the changes and re-fetching the object to  
obtain an MD5. The only real solution here is to refactor the API to  
return a modseq/timestamp (let's call these "syncstamps"), after each  
message change, which would of course be a BC break.