On Apr 2, 2005 7:21 PM, Stefan Guggisberg <[EMAIL PROTECTED]> wrote: > hi edgar > > On Apr 1, 2005 6:24 PM, Edgar Poce <[EMAIL PROTECTED]> 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 > > >
