hi again,
when an itemstate is requested it's always a state that is either
known by the normal ism or a virtual ism. when a non-virtual state is
requested, it usually exists and the negative cache is not needed. if
a virtual state is requested, the normal ism has a miss, and asks the
virtual ism which has a hit. so i assume your usecase is related to
versioning :-). so i think that your solution is correct to cache the
misses in the hasNonVirtualItemState() call.
regards, toby
On 1/24/07, Tobias Bocanegra <[EMAIL PROTECTED]> wrote:
hi Martijn,
thanks for your post. we once thought of implementing a negative cache
as well, but came to the conclusion that it's not so easy. i can't
remember the exact reasoning :-) but it had something to do with the
virtual item states and with the flushing of the negative caches.
but we could look into this again. can you file a jira issue? thanks.
regards, toby
On 1/22/07, Martijn Hendriks <[EMAIL PROTECTED]> wrote:
> Hi,
>
> 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
> <GX> creative online development B.V.
>
> t: 024 - 3888 261
> f: 024 - 3888 621
> e: [EMAIL PROTECTED]
>
> Wijchenseweg 111
> 6538 SW Nijmegen
> http://www.gx.nl/
>
--
-----------------------------------------< [EMAIL PROTECTED] >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
--
-----------------------------------------< [EMAIL PROTECTED] >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
