I need caching for an application I'm working on that will distribute
content around a network. I need temporary storage while a node is being
distributed. It's sort of a data bus/messaging system. Once a node has
been distributed I will, usually, no longer need it. But in some
scenarios the distribution could be long after the node becomes
available (is created) so caching is not as important as persistence.
Jackrabbit appears to be a nice fit as it would provide temporary, fast
access storage in some cases but more permanent in others.
Harry
avim wrote:
Where can I find more information(general/specific) about about
JCR/Jackrabbit caches?
Stefan Guggisberg wrote:
On 3/19/07, Harry Moore <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
Sent: Fri 3/16/2007 10:45 PM
To: [email protected]
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
--
Harry Moore
Eye Street Software
Office: 888-252-2085 ext. 3013
Cell: 617-429-3666
