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

Search Results: 5 of 14 [ <<First <Prev Next> Last>> ] [ Return to Search Results ]

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