[
https://issues.apache.org/jira/browse/OAK-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14966803#comment-14966803
]
Marcel Reutegger commented on OAK-2592:
---------------------------------------
I see the following alternatives to findAndModify():
- First ensure the document is cached and then perform a conditional update()
on the modCount. If it fails, repeat until it succeeds. This option does not
work well, when there are concurrent updates from multiple cluster nodes on the
same document and we may run into a liveness problem.
- Perform an unconditional update and then read the document from MongoDB.
Create a before document by applying the reverse operation on the document. The
document may be slightly different from what findAndModify() returns. The
assumed _modCount may not exactly match the state of the document before the
update was applied. Between the update and the read operation another update
from another cluster node may slip in and update the _modCount. This wouldn't
be a problem, because _modCount is an implementation detail of the
MongoDocumentStore. There's another problem, though. Some operations cannot be
reverted. Setting a top level property in a document overwrites the previous
value. At least for the final update on the commit root document, this wouldn't
be a problem. The only top level property changed by such a update is _modified
(in addition to the _modCount).
> Commit does not ensure w:majority
> ---------------------------------
>
> Key: OAK-2592
> URL: https://issues.apache.org/jira/browse/OAK-2592
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, mongomk
> Reporter: Marcel Reutegger
> Assignee: Marcel Reutegger
> Labels: resilience
> Fix For: 1.3.9
>
>
> The MongoDocumentStore uses {{findAndModify()}} to commit a transaction. This
> operation does not allow an application specified write concern and always
> uses the MongoDB default write concern {{Acknowledged}}. This means a commit
> may not make it to a majority of a replica set when the primary fails. From a
> MongoDocumentStore perspective it may appear as if a write was successful and
> later reverted. See also the test in OAK-1641.
> To fix this, we'd probably have to change the MongoDocumentStore to avoid
> {{findAndModify()}} and use {{update()}} instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
