[
https://issues.apache.org/jira/browse/OAK-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13577654#comment-13577654
]
Marcel Reutegger commented on OAK-591:
--------------------------------------
bq. Any attempt of leveraging this for a cache in an upper layer will
necessarily break encapsulation.
This depends on what the contract is. We certainly have to use only features
that are specified in the MicroKernel API. What we have right now, is a rather
simple tree version model exposed by the MicroKernel API, which does now allow
us to build an efficient cache on top of it. I don't agree with you that it
means the cache is necessarily in the wrong place, but it just isn't that
useful. Moving the cache down to the MicroKernel is one option, but I think we
should also consider changing the MicroKernel API.
AFAIU introducing :id and :hash was one attempt. The downside of these two
properties is that it introduces a new method to address nodes, which later can
become a problem. E.g. when you want to call another method, which again
expects a path+revision.
> Improve KernelNodeStore cache efficiency
> ----------------------------------------
>
> Key: OAK-591
> URL: https://issues.apache.org/jira/browse/OAK-591
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Affects Versions: 0.6
> Reporter: Marcel Reutegger
> Attachments: mk.log.gz, OAK-591.patch
>
>
> The cache in KernelNodeStore references entries with a path+revision combo.
> This mapping quickly becomes inefficient when there are writes on the
> repository. Whenever something is changed, the complete cache basically
> becomes invalid and oak-core needs to re-fetch nodes again, even though they
> didn't change. The attached test shows this behaviour. The test initially
> creates 10 nodes and lets a thread read those nodes repeatedly. To make the
> test somewhat realistic the reader acquires a new session in every run
> through the loop. This is to simulate e.g. a request which acquires a new
> session every time (Apache Sling does it that way). At the same time writes
> occur but in a separate part of the repository. As can be seen in the logs,
> the nodes are read from the MicroKernel whenever something changes anywhere
> in the repository. Obviously this is no limited to the test nodes. The log
> also shows repeated reads to node type, user and index nodes. None of them
> change while the test runs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
