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

Michael Dürig commented on OAK-591:
-----------------------------------

Isn't what you describe a problem to any such system, not only for the current 
Microkernel/API? After all, the fact that the underlying storage layer can do 
more efficient caching relies on an implementation detail: namely that nodes 
are shared across revisions (i.e. cheaply copied). Any attempt of leveraging 
this for a cache in an upper layer will necessarily break encapsulation. 

To me this seems to be a further indication that the cache is in the wrong 
place. As [~jukkaz] mentioned yesterday, oak-core does neither know enough 
about how the data is stored neither on how it is consumed. 
                
> 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

Reply via email to