jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: jackrabbit deployment model 1
Date Mon, 18 Jul 2005 09:45:02 GMT
On 7/15/05, Marcel Reutegger <marcel.reutegger@gmx.net> wrote:
> 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.

i had a quick glance at JBoss Cache as well. i agree that it looks 
promising, but not for use in jackrabbit's core. 

for one JBoss Cache is hierarchical (i.e. path-based) whereas jackrabbit's
internal data model is flat (id-based). 

i don't think that crucial components at the very core should be pluggable.
the contract of SharedItemStateManager is quite complex. if it's not
implemented correctly the stability and integrity of the repository is at 
great risk. do you know of any rdbms engine that supports pluggable 
caches for its internal row buffers? i don't.

> 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

good starting point!

cheers
stefan

> 
> 
> regards
>   marcel
>

Mime
View raw message