[ 
https://issues.apache.org/jira/browse/OAK-4069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15741354#comment-15741354
 ] 

Tomek Rękawek commented on OAK-4069:
------------------------------------

Attached [^OAK-4069-3.patch] in which I don't try to resolve the current user 
roles but just check the serverStatus command reply (if it's empty then it'll 
fallback to isEnabled()). It'd be hard to use the roles, as the clusterMonitor 
may be part of some other role.

> 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-3.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)

Reply via email to