jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: jackrabbit deployment model 1
Date Fri, 15 Jul 2005 08:11:46 GMT
Hi Julien,

Julien Viet wrote:
> the other ideas would to plug JBoss Cache (distributed transactionnal 
> cache) in jackrabbit but there are no hooks to
> do that so far. My trick about disabling the jackrabbit cache is that I 
> reimplemented a jackrabbit filesystem on top
> of JBoss Portal to provide replication. It worked but some tests are not 
> passing in jackrabbit suite and I did not check
> further (no time). Having such an integration would require I think 
> modifications in jackrabbit. Perhaps JBoss Cache
> should be plugged at the SharedItemState level.

We have ongoing (tough private coffee break) discussions here at day 
about clustering. The reason why we are not pushing such a feature right 
now is, that it would require a redesign of one of the very central core 
pieces of jackrabbit. I can only speak for myself, but I rather want to 
release a stable single instance version of jackrabbit, than a release 
with clustering support that turns out to be not reliable.

> If you think about it, JBoss Cache does already what jackrabbit is doing 
> is some ways. It is possible to configure it
> to have a cache loader that can load and store cache entries. It is 
> comparable to SharedItemStateCache and PersistenceManager
> you have in your codebase. The difference is that the cache can be 
> replicated and also provide a configurable isolation level, also
> we are in the process of adding optimistic locking.

I had a look at JBoss Cache the other day, and I think it looks 
promissing indeed.
With the risk that someone will probably try to kill me on monday I 
opened a jira issue to start a more technical discussion about 
clustering and what is needed to make this possible in jackrabbit:


View raw message