On Mon, Feb 16, 2009 at 9:02 PM, defeng <defeng...@gmail.com> wrote: > > I am using Jackrabbit 1.4.4 clustering. DB for persistent manager, and NFS > for datastore. Everything works well, but since the Jackrabbit uses a > Cluster-wide lock, many times, other JCR clients need to wait for a long > time to acquire the Global lock. > > To solve this issue, I want to use a distributed cache(memcached) in > SharedISM. To disable cache in SessionISM and LocalISM (I did not use XA ). > So there is no necessary to sync any data in cache. In addition, I donot > need to register Namespace or Nodetype at runtime. The only thing is to sync > local search index in the Looping of ClusterNode. (I did not use > AccessManager in Jackrabbit) > > When updating an item, a distributed lock is acquired. It is used to ensure > the data consistence between persisten manager and distributed cache > (2-phase commit). > > Is the proposal feasible? Any comment is highly appreciated!
i don't think that this would work without a major redesign of jackrabbit's core architecture. SharedISM 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. similarly, 'caches' in SessionISM and LocalISM are crucial for jackrabbit's support of isolation levels. changing the semantics/behavior of those 'caches' would easily lead to data corruption/lost updates etc. cheers stefan > -- > View this message in context: > http://www.nabble.com/Clustering-w--distributed-cache-tp22044598p22044598.html > Sent from the Jackrabbit - Dev mailing list archive at Nabble.com. > >
