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 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 >
