jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: cluster and cache question
Date Sat, 02 Apr 2005 17:25:32 GMT
On Apr 2, 2005 7:21 PM, Stefan Guggisberg <stefan.guggisberg@gmail.com> wrote:
> hi edgar
> 
> On Apr 1, 2005 6:24 PM, Edgar Poce <edgarpoce@gmail.com> wrote:
> > Hi
> >
> > I'm trying to use jackrabbit in a cluster scenario. Since jdbc calls are
> > rather expensive caching results is a common practice, but as you all
> > pointed PMs are not designed to be smart. So, do you think caching
> > should be in the PM?, it should be somewhere else?, it shouldn't be at
> > all? any more option?
> 
> 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

sorry, i posted the wrong url. the correct url is:
http://article.gmane.org/gmane.comp.apache.jackrabbit.devel/1223

> 
> 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.
> 
> regarding clustering:
> clustering is a very interesting topic and we had quite a few discussions
> on how it could be supported in jackrabbit. 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.
> 
> 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.
> 
> cheers
> stefan
> 
> >
> > I'm thinking of a cluster scenario with
> > jdbc PM + distributed cache + jackrabbit
> > instead of
> > any PM + jackrabbit + rmi server + rmi client
> >
> > I prefer the first config because there are products that build the
> > cache on each server and don't pass the cached objects around the cluster.
> >
> >   It seems I often feel tempted to bad practices :(, so I'd like to know
> > your opinion before taking a decision.
> >
> > thanks in advance
> > edgar
> >
>

Mime
View raw message