Return-Path: 
 <dev-return-10622-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org>
Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org
Received: (qmail 41053 invoked from network); 2 Feb 2007 14:44:28 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 2 Feb 2007 14:44:28 -0000
Received: (qmail 23906 invoked by uid 500); 2 Feb 2007 14:44:34 -0000
Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org
Received: (qmail 23536 invoked by uid 500); 2 Feb 2007 14:44:33 -0000
Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@jackrabbit.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@jackrabbit.apache.org>
List-Post: <mailto:dev@jackrabbit.apache.org>
List-Id: <dev.jackrabbit.apache.org>
Reply-To: dev@jackrabbit.apache.org
Delivered-To: mailing list dev@jackrabbit.apache.org
Received: (qmail 23416 invoked by uid 99); 2 Feb 2007 14:44:33 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Feb 2007 06:44:33 -0800
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Feb 2007 06:44:26 -0800
Received: from brutus (localhost [127.0.0.1])
	by brutus.apache.org (Postfix) with ESMTP id 144DA7142D0
	for <dev@jackrabbit.apache.org>; Fri,  2 Feb 2007 06:44:06 -0800 (PST)
Message-ID: <12484373.1170427446080.JavaMail.jira@brutus>
Date: Fri, 2 Feb 2007 06:44:06 -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
X-Virus-Checked: Checked by ClamAV on apache.org


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

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

    Attachment: MLRUItemStateCache.java
                CacheManager.java
                SharedItemStateManager.java

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