[GitHub] [couchdb] jcoglan edited a comment on issue #3939: Race condition causing slow responses to `PUT /db/doc` with `multipart/related` attachments

[GitBox <gi...@apache.org>]

jcoglan edited a comment on issue #3939:
URL: https://github.com/apache/couchdb/issues/3939#issuecomment-1048934037


   @kocolosk This has prompted me to rethink how this would work for normal (`new_edits != false`) writes. For replication writes, both requests can succeed b/c replication writes can add revs anywhere in the tree; if the revs already exist, no problem.
   
   For normal writes, one of these concurrent requests _must_ fail, or you have a causality violation. Let's refer to the writer procs on `B`, `C` and `D` for requests 1 and 2 as `B1`, `C1`, `D1` and `B2`, `C2`, `D2`. In our example above, `B1` succeeds first, before request 2 begins. This means `B2` _must_ fail, because the `rev` param in these identical requests is no longer a leaf in node B's copy of the DB.
   
   The rest of the processes `C1`, `D1`, `C2`, `D2` are still ongoing and there's nothing forcing them to finish in any particular order. It should be the case that if `C1` succeeds, then `C2` fails and vice versa, same for the `D` writers. This in turn should mean that only one request achieves quorum, but it _could_ be request 2, even if this is unlikely in general.
   
   So this still should not result in a consistency violation, but it's worth seeing if there's any way this allows both requests to succeed.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@couchdb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org