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:
http://issues.apache.org/jira/browse/JCR-169
regards
marcel