[ https://issues.apache.org/jira/browse/OAK-4069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735439#comment-15735439 ]
Tomek Rękawek commented on OAK-4069: ------------------------------------ I added the role check. It seems that the {{storageEngine.supportsCommittedReads=true}} doesn't mean that the {{--enableMajorityReadConcern}} has been used. I haven't found an API method that allows to check whether the readConcern can be really used, so I created a new method isMajorityReadConcernEnabled() that tries to run a simple find() with readConcern=majority and catches the exception (if there's any). If the user doesn't have the appropriate role then isSupported() method invokes the isEnabled() (as the second implies the first). > Use read concern majority when connected to a replica set > --------------------------------------------------------- > > Key: OAK-4069 > URL: https://issues.apache.org/jira/browse/OAK-4069 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk > Reporter: Tomek Rękawek > Assignee: Tomek Rękawek > Labels: resilience > Fix For: 1.6, 1.5.16 > > Attachments: OAK-4069-2.patch, OAK-4069.patch > > > Mongo 3.2 introduces new query option: {{readConcern}}. It allows to read > only these changes that have been already committed to the majority of > secondary instances. > It prevents stale reads - a situation in which a change has been committed on > the primary (and read from it), but due to the network partition a new > primary is elected and the change is rolled back. > We should use this new option (together with {{w:majority}} implemented in > OAK-3554) when running Oak on MongoDB replica set. > References: > * [Jepsen: MongoDB stale > reads|https://aphyr.com/posts/322-jepsen-mongodb-stale-reads] > * [MongoDB documentation: Read Concern > in|https://docs.mongodb.org/manual/reference/read-concern/] -- This message was sent by Atlassian JIRA (v6.3.4#6332)