[
https://issues.apache.org/jira/browse/OAK-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14505002#comment-14505002
]
Michael Marth commented on OAK-2792:
------------------------------------
[~catholicon], some comments:
# if we find this to be useful (which I am quite convinced we will) then we
should consider to implement it in a way so that it can also be applied to
non-MongoDB persistence layers. (some cloud DBs that have similar concepts to
log tailing come to mind) - so basically should not be specific to MongoMK
# afaik there are 2 possibilities on which cache to update: the in-mem cache
within the DocumentMK or the persistence cache. Also, we have 2 possibilities
what to do: either flush invalid items or proactively write new items into the
cache. If we go with the persistent cache (which is immutable) then the latter
decision is simple: would be to proactively fill.
# *If* we go with proactively fill IMO this makes sense under the underlying
assumption that content written in one Oak instance is likely to be read in
other instances soon later. That's a big assumption - so we need to make sure
we have test cases that model our read/write assumptions (or intended
improvements). Maybe we can extend the scalability test framework for such
tests?
> Investigate feasibility/advantages of log-tailing mongo op-log to invalidate
> cache
> ----------------------------------------------------------------------------------
>
> Key: OAK-2792
> URL: https://issues.apache.org/jira/browse/OAK-2792
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
> Reporter: Vikas Saurabh
>
> It is observed that current cache invalidation logic has some issues
> (OAK-2187) and there is an Oak issue (OAK-2646) to investigate alternative
> cache invalidation logic. One such option is to log-tail mongo op-log
> (specific to mongo back-end obviously :)).
> This task is for investigating that approach.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
