jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harry Moore <harry.mo...@eyestreet.com>
Subject Re: node caching
Date Wed, 21 Mar 2007 11:14:39 GMT
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 <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
>>>
>>>
>>>       
>>     
>
>   

-- 
Harry Moore
Eye Street Software
Office: 888-252-2085 ext. 3013
Cell: 617-429-3666


Mime
View raw message