Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <5266051.1170567125785.JavaMail.jira@brutus>
Date: Sat, 3 Feb 2007 21:32:05 -0800 (PST)
From: "Martijn Hendriks (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Updated: (JCR-731) Can the caching mechanism be improved?
In-Reply-To: <5561703.1170427325812.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Martijn Hendriks updated JCR-731:
---------------------------------

    Attachment: JCR-731.diff

Hi Stefan,

Here is the diff w.r.t JackRabbit 1.2.1. Please note that we also applied Jaka Jaksic's patch for JCR-725 to the CacheManager.

Martijn

> 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.