[
https://issues.apache.org/jira/browse/OAK-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14506485#comment-14506485
]
Vikas Saurabh commented on OAK-2792:
------------------------------------
[~mmarth], current idea was around invalidation, so I didn't think about
persistent cache. But, yes, sure we can look at doing pro active fetch apart
from just invalidation.
About, abstracting log tailing logic to not tie too strongly with Mongo - sure
would take care of it..
[~mreutegg], Chetan and i thought that we can use op log changes to just get
ids to invalidate. Actual invalidation can remain in background thread. In
worst case, we might excessively invalidate despite changes not yet visible -
but even then this might be cheaper than blanket invalidation if time exceeds
(as being discussed in OAK-2793).
Btw, I'm currently looking at OAK-2793 as it is fairly straightforward and it's
results might get us some data around access patterns and usability of mem
cache.
> 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)
