Thanks for the response!
I would like to solicit a bit more expanded definition of atomicity there — if possible.
Maybe an example could help.
Each document in my collection has a unique identifier (the
_id field is naturally used to store it) and an integer field which may be though of as a version (or revision) of a datum identified by a particular
The piece of software making use of that collection periodically receives new revisions of particular documents (from the outside) and has to update them in the collection.
No matter which exactly MongoDB operation we intend to use for that, the logic for the replacement has to be this: “find a document with such and such
_id and with the version less than what we are about to use as a replacement”.
That is, if the collection has a document with a version greater or equal to than what we have, do nothing, otherwise — perform replacement.
So far so good, but now let’s introduce more “updaters”: now more than a single client may receive an updated document and will attempt to replace its existing version in the collection.
What I’m afraid of — in this setting — is a following situation:
- The collection has a document with
- One of the updaters attempts to update this document with the data having
- Another one attempts to update this document with the data having
- Now the
replaceOne operation issued by the first updater finds the document with the
version field lower than what the updater is about to update it with, and so the replacement may proceed.
- At the same time, the concurrently running second updater finds the same document, and the query also gives it the go-ahead so the replacement may proceed.
What I’m asking for is whether it’s possible that in the described case the replacement performed by the second updater (wanting to replace with
version=3) might happen in between the query performed by the first updater (wanting to replace with
version=2) allows it to proceed and it actually stores its document?
This way, there is a possibility of updating the document to a lower-than-should-have-been
version irrespective of the check performed by the operation’s query.
That is what bothers me: the atomicity of the query and the update — as a sequence of operations.
(Sorry for the wall of text but I have tried hard to explain this problem.)