Thank for you reply.

I used the memcache in other projects before, the performance seems good.
Facebook did some enhancement on it.
http://github.com/blog/267-facebook-s-memcached-on-github.
 You are right, we have to serialize/deserialize objects. But that's the
price we have to pay for the clustering, is it?

In current clustering, one operation (for example, modify a property) will
block entire clustering. It's terrible for us. we want to change the
cluster-wide lock to item-wide, based on distributed lock with memcached.

Another thought is to disable clustering/journal configuration. All cluster
nodes use same distributed cache, DB and NFS.  Since no local cache again,
we only need to use JMS (activemq) to notify Local Search Index udpating.

I noticed "Native Clustering" was on the Jackrabbit Roadmap - 3.0. What's
the schedule for 3.0?


Thomas Müller-2 wrote:
> 
> Hi,
> 
> Do you have experience with memcached for Java?
> http://www.thimbleware.com/projects/jmemcached
> From what I read it is a client-server solution, you would have to
> serialize
> / deserialize objects, which would slow down things a lot (compared to
> having the cache in the Java heap memory).
> 
> Regards,
> Thomas
> 
> 
> 
> 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!
>> --
>> 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.
>>
>>
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Clustering-w--distributed-cache-tp22044598p22059652.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.

Reply via email to