jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martijn Hendriks (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-731) Can the caching mechanism be improved?
Date Mon, 12 Feb 2007 19:49:05 GMT

    [ https://issues.apache.org/jira/browse/JCR-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472398

Martijn Hendriks commented on JCR-731:

Stefan, thanks for your feedback!

I agree that using the exception mechanism for checking the existence of item states should
be avoided. I noticed, however, that the commen code pattern "if (node.hasNode("a")) Node
aNode = node.getNode("a"); " uses 4 calls to the database if the node "a" exists, but is not
yet in the cache. The pre-loading in hasNonVirtualItemState reduces this to only 1 call. The
usage of an exception can quite easily be avoided, I think, by letting the persistence manager
not throw an "NoSuchItemStateException" if a state doesn't exist, but instead just return
With pre-loading there is of course the drawback that a huge state is loaded, but not requested
by the repository user. I have the feeling that this is uncommon. 

The patch indeed is non-trivial and needs carefull reviewing. I unfortunately did not take
the Jackrabbit code style into account... I'm happy to provide a fixed patch that solves this
if needed.

As for the benchmark you mention, I will attach a test class that spawns a number of threads
that randomly read from a repository. Especially the impact of the pre-loading is significant:
the test runs approximately 1.7 times as fast. Additional use of the MLRU and CacheManager
patch improves this a bit to 1.8.

Best wishes,


> Can the caching mechanism be improved?
> --------------------------------------
>                 Key: JCR-731
>                 URL: https://issues.apache.org/jira/browse/JCR-731
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: core
>            Reporter: Martijn Hendriks
>         Attachments: CacheManager.java, JCR-731.diff, MLRUItemStateCache.java, SharedItemStateManager.java
> Hi all,
> We've identified the method "getNonVirtualItemState" in the SharedItemStateManager as
a hot spot in our application. To avoid the contention in "getNonVirtualItemState", we have
pulled the isCached call out of the synchronized block and re-implemented the MLRUItemStateCache.
It uses a HashMap that contains the ItemId-ItemState mapping and a ReadWriteLock to replace
all synchronized blocks in the code. The implementation of "shrinkIfRequired" unfortunatly
got much more expensive as the entryset of the HashMap must be sorted by accesscount. This
method then clearly is a bottleneck. We solved this by changing the CacheManager a bit: the
"resizeAll" method avoids the eviction of items out of caches as long as possible.
> These changes work out really well for our application. I have attached the changed files;
comments/feedback are very welcome!
> Regards,
> Martijn Hendriks
> <GX> creative online development B.V.
> t: 024 - 3888 261
> f: 024 - 3888 621
> e: martijnh@gx.nl
> Wijchenseweg 111
> 6538 SW Nijmegen
> http://www.gx.nl/ 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message