Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of stefan.guggisberg@gmail.com
 designates 64.233.182.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=ujSgSyCeQK53FD7G4982bXXXEwEmezDbBxhYjbmAWPTKqqucMkWa1D7s/6VuJMBI8OFx2S1v71Qo9JdP1/k/HiW0avy+v15NVcT12oCIiExG+rjRRlxDdz8lAPCMlOHLjAlIx0L1e9ZVaa5T3YQHOhsb6jywWCCxjXSAH41VNO0=
Message-ID: <90a8d1c00703190703t7cde943s12c4cdd15c9a257d@mail.gmail.com>
Date: Mon, 19 Mar 2007 15:03:18 +0100
From: "Stefan Guggisberg" <stefan.guggisberg@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: node caching
In-Reply-To: <45FE8D05.8020408@eyestreet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <45FB0B24.6050600@eyestreet.com> <45FB564B.8040006@eyestreet.com>
	 <B0DF9E6A0427F44E8BF4EEF9F433DB4F0652BF84@EXCHANGE.genesis.csps.com>
	 <8be731880703171039n4a7ebc30x973ab2e91dfd92a3@mail.gmail.com>
	 <45FE8D05.8020408@eyestreet.com>

On 3/19/07, Harry Moore <harry.moore@eyestreet.com> wrote:
> So nodes are cached regardless of persistence manager? That is good to

yes, correct.

> know. Is it fixed size, most-recently-used?

item states (representing the raw node/property data) read from/written to
the persistence layer are cached by an ItemStateReferenceCache instance:

http://jackrabbit.apache.org/api-1/org/apache/jackrabbit/core/state/ItemStateReferenceCache.html

the eviction policy is pluggable by design and currently hardcoded to
use MLRUItemStateCache which is allocated a certain amount of memory.
oldest entries are flushed once the cache size has exceeded this limit.

we've experimented with different eviction policies (LRU etc), the very simple
current (FIFO) seems to be vey efficient overall.

just being curious: why did you ask for node caching in the first place?
did you experience inadequate read performance?

cheers
stefan

>
> Harry
>
> Tobias Bocanegra wrote:
> > hi,
> > please note, that there are several layer of caching present in
> > jackrabbit.
> > there is a cache of the items of the itemmanager (session scope), a
> > cache of the itemstates of the localeitemstatemanager (session scope),
> > a cache of the itemstates in the shareditemstatemanager (global
> > scope).
> >
> > there is no need for an additional caching.
> > regards, toby
> >
> > On 3/17/07, Danner, Russ <DannerR@csps.com> wrote:
> >>
> >> what are the cons of that approach?  Is there a background thread
> >> actually persisting the changes?  What happens when the machnine
> >> fails for some reason? From the javadoc it looks like a bad option...
> >> like a toy that one would use for testing (it says the class should
> >> only be used for testing.)  Maybe it could be adapted to act as a cache.
> >>
> >> -R
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Harry Moore [mailto:harry.moore@eyestreet.com]
> >> Sent: Fri 3/16/2007 10:45 PM
> >> To: users@jackrabbit.apache.org
> >> Subject: Re: node caching
> >>
> >> Looks like InMemPersistenceManager persistance is the way to go.
> >>
> >> Harry Moore wrote:
> >> > Is there a way to flag a node, set of nodes or some other segment of a
> >> > jackrabbit repository for high-speed access? That is, cache frequently
> >> > accessed nodes in memory (with write-through update) so they can be
> >> > accesses very quickly.
> >> >
> >> > Thanks,
> >> >
> >>
> >> --
> >> Harry Moore
> >> Eye Street Software
> >> Office: 888-252-2085 ext. 3013
> >> Cell: 617-429-3666
> >>
> >>
> >>
> >
> >
>
> --
> Harry Moore
> Eye Street Software
> Office: 888-252-2085 ext. 3013
> Cell: 617-429-3666
>
>