jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Huber <shub...@jahia.com>
Subject Re: cluster and cache question
Date Mon, 04 Apr 2005 16:41:33 GMT
Stefan Guggisberg wrote:

>On Apr 4, 2005 11:55 AM, Simon Gash <Simon.Gash@gossinteractive.com> wrote:
>  
>
>>On the other hand the rest of you might want to access a session across
>>a cluster, I think that would significantly increase the complexity of
>>the design. I'm a fan of IOC (inversion of control) wouldn't the best
>>solution be a pluggable design so that the JackRabbit users can provide
>>their own particular brand (Tangsol, OS ...) ? Who could possibly be
>>against a pluggable design :)
>>    
>>
>
>i am ;) 
>don't get me wrong, i am not against pluggable design in general but 
>i am strictly against making *core* components pluggable. jackrabbit's 
>stability, integrity and performance directly depends on the design 
>and quality of implementation of such core components. i don't want to 
>put that at risk.
>  
>
Although I do understand that performance needs to be seriously 
considered, I think that in the case of the Cache implementation it 
might be a problem if it cannot be pluggeable. What if the default 
implementation doesn't scale well ? Or that on some configurations the 
purging algorithm doesn't work well ?

We do have a pluggeable system for the persistence managers, and 
therefore I don't see what the big problem would be with a pluggeable 
cache implementation in terms of performance, provided we don't use 
reflection, but simply interfaces.

Basically something like

Cache cache = CacheFactory.getCache(Object cacheKey)
where Cache would be an interface

The immediate way of doing it I think would be to replace the Map in 
ItemCache with a Cache interface, and that would provide the needed 
functionality.
We could have a default implementation that would default to what we do 
right now, that is a ReferenceMap.

In terms of performance, the cost would be one method call more for 
every cache hit in the case of the default implementation. I don't 
realize what kind of performance goal we need to achieve, but it seems 
like it wouldn't be a huge cost.

The main problem I see with this implementation is that the 
ItemStateCache uses soft references, which means that other cache 
implementations might not be immediately pluggeable if we rely a lot on 
the soft referencing mechanism (this is an area of Jackrabbit that I 
don't know that well).

Maybe another solution would be to simply deactivate caching and use a 
PersistenceManager layer cache for clustering setups. For example by 
using Hibernate's cache and clustering support and completely deactivate 
the ItemStateManager's caches. I don't know what this would do to 
performance though...

Regards,
  Serge Huber.

>cheers
>stefan
>
>  
>


Mime
View raw message