jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edgar Poce <edgarp...@gmail.com>
Subject Re: cluster and cache question
Date Sat, 02 Apr 2005 21:08:29 GMT
hi stefan

Stefan Guggisberg wrote:
> ItemState instances are cached on multiple layers. Please have a look
> at dominique's earlier post which IMO explains jackrabbit's design 
> quite nicely:
> http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/1172
thanks for the reference.

> the SharedItemStateManager is at the bottom layer and caches 
> ItemState instances read from the PM. this memory-sensitive cache, 
> apart from helping to reduce PM calls, guarantees that there's only 
> *one* ItemState instance for any given id on this layer. this is crucial 
> for jackrabbit's support of isolation levels. caching in the PM would 
> therefore IMO be redundant if not disadvantageous because it would
> use up (memory) resources that could be used more efficiently by 
> jackrabbit.
got it.

> regarding clustering:
> clustering is a very interesting topic and we had quite a few discussions
> on how it could be supported in jackrabbit. 
is there an archive of this?

 > clustering can IMO not be
> entirely delegated to the PM. it has to be tackled on a higher level.
> the sticking point is how to synchronize the multiple jackrabbit instances 
> in a cluster.
Have you seen the oscache approach for clustering? it seems interesting. 
I'm just thinking out loud, Local and Shared ItemStateManagers could 
favor composition over inheritance. The current ItemStateCache 
implementation is a good fit for the first, and an oscache like approach 
could be a good choice for the latter in a clustering scenario.

Maybe this could be a deployment decision, with a "shared-cache" tag in 
the config file that leaves to the deployer the cache strategy selection 
for shared ItemStates.

A pluggable cache for shared item states would also be useful for 
network deployments with or without clustering. Those who chose a rdbms 
backend would be able to to use a cache that relies also in the local 
filesystem, and not only in mem.

> there's no easy answer to that and it would certainly require considerable
> work in jackrabbit's core. as our main priority is getting jackrabbit version 
> 1.0 out clustering support has to wait i'm afraid.
It has sense. It seems many people is waiting for a release in order to 
use it in production.

Sorry for being such a pain, I'm becoming a jackrabbit fun and I'd like 
to use it on any project I get involved.


View raw message