Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <15154609.1174031830812.JavaMail.jira@brutus>
Date: Fri, 16 Mar 2007 00:57:10 -0700 (PDT)
From: "Martijn Hendriks (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-716) Performance: caching negative results
In-Reply-To: <20491820.1169634709268.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-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481516 ] 

Martijn Hendriks commented on JCR-716:
--------------------------------------

The recently added bundle persistence managers cache non-existing NodeIds. So I guess that this resolves this issue?

> Performance: caching negative results
> -------------------------------------
>
>                 Key: JCR-716
>                 URL: https://issues.apache.org/jira/browse/JCR-716
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: core
>            Reporter: Martijn Hendriks
>         Attachments: SharedItemStateManager.java
>
>
> We recently have been looking at the performance of JackRabbit and noted that the SharedItemStateManager does not cache negative results. For instance, when "hasItemState" returns false, then this negative result is not cached and a subsequent call with the same ItemId will again query the database (if the item has not been added and cached yet). We think, however, that caching such negative results might improve the performance significantly for some applications.
> I've tried to add a simple negative-caching scheme. ItemIds are negatively cached in the method "hasNonVirtualItemState" when the persistence manager returns "false". Cache eviction occurs in the method "getNonVirtualItemState" when a state is loaded. It also seems necessary to evict ItemIds in the methods "stateCreated" and "has/getItemState" (when one of the virtual providers returns something), because when an ItemId is neg-cached, it might still be provided by one of the VISP. The negative cache can then be used in the method "hasNonVirtualItemState" like this:
> if (cache.isCached(id)) {
>      return true;
> } else if (negativeCache.isCached(id)) {
>      return false;
> }
> Although all JackRabbit tests succeeded during compilation and our application seemingly behaved ok, I still doubt that my implementation is completely correct (I don't know the ins and outs of the SharedItemStateManager and made some assumptions). We are, however, quite eager to investigate this further as our application is 15% faster in an important use case with this very simple negative caching scheme enabled.
> Is there any previous work on something like this in JackRabbit? How difficult is a solid implementation?
> Regards,
> Martijn Hendriks

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