we are considering using jackrabbit in JBoss Portal for our CMS and so
far, the only way we have to use it is having
an architecture where the repository runs as a singleton (we have an HA
singleton service) on the cluster
and other nodes use proxies to talk to the master node. Also we would
add lot of caching but not at the
JCR level but at the layer above which is the CMS object model in order
to provide a fast access to clients.
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.
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.
Edgar Poce wrote:
Hi richard
On 7/14/05, Guozhong (Richard) Wang <[EMAIL PROTECTED]> wrote:
Julien and Marcel,
But if the internal cache is disabled as Julien did,
in theory should multiple Repos be able to simultaneously access the
storage?
I don't think so. The concurrency control is done at the
SharedItemStateManager level (see
http://issues.apache.org/jira/browse/JCR-164). So, two jackrabbit
instances accessing the same physical storage will probably lead to
corrupt data. And among other problems, the search index on each
instance would be unaware of the changes made by the other, and the
observation wouldn't work as expected.
As marcel already said, clustering is not that easy
BR,
edgar
thanks,
Richard
Julien Viet wrote:
If you disable the cache then you reload everything all the time and
should achieve the desired effect, but performances will suffer a lot.
By the way I disabled the cache in jackrabbit (I simple modified the
code to have the SharedItemCache have the put() do a noop).
Some tests were not passing with that change. I think it is not normal
to have the tests failing when the cache is disabled (even if it
is uses a hack to make it not effective)
Marcel Reutegger wrote:
Julien Viet wrote:
because jackrabbit uses an internal cache that you cannot disable.
and even if you would be able to disable the cache, one instance had
to tell the other one that something has changed on disc. otherwise
you would have to scan the filesystem all the time for possible changes.
clustering is not that easy ;)
regards
marcel
--
Julien Viet
JBoss Portal Lead Developer
