[
https://issues.apache.org/jira/browse/OAK-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978055#comment-13978055
]
Thomas Mueller commented on OAK-1645:
-------------------------------------
There are some changes I don't quite understand, for example a change from
ReadPreference.secondaryPreferred() to ReadPreference.primary() in
MongoMissingLastRevSeeker. Maybe this was a bug? If yes, I think it should be
tracked separately. Such changes (bugfixes) are fine and should go into 1.0,
but I believe structural changes are risky.
> Route find queries to Mongo secondary in MongoDocumentStore
> -----------------------------------------------------------
>
> Key: OAK-1645
> URL: https://issues.apache.org/jira/browse/OAK-1645
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Fix For: 1.1
>
> Attachments: OAK-1645-1.patch, OAK-1645-2.patch
>
>
> Currently MongoDocumentStores routes all find query to primary. In some case
> it is possible to route the call to secondary safely
> *1. Make use of Max Age*
> Find call takes a maxAge parameter
> {code}
> find(Collection<T> collection, String key, int maxCacheAge)
> {code}
> If the maxAge is high then its safe to route the call to secondary as the
> caller explicitly does not want the latest version. This would be specially
> useful in fetching split documents as such docs are immutable. So logic can
> first check in secondary and if not found can make a call to primary
> *2. Make use of modified time of parent*
> When fetch a path its possible to check if the parent exist in the cache or
> not. if parent is present in cache we can make use of its {{modified}} time.
> If the modified time is old it indicates that subtree under it has also not
> been modified. So call for such child can be routed to secondary
> In both cases we need to have a time interval defined to switch the logic to
> secondary call
--
This message was sent by Atlassian JIRA
(v6.2#6252)
