Stefan Guggisberg wrote:
On Apr 4, 2005 11:55 AM, Simon Gash <[EMAIL PROTECTED]> wrote: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 ?
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.
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
