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:57:12 GMT
On 7/18/05, Julien Viet <julien@jboss.org> wrote:
> yes, at the end jackrabbit is a database.
> 
> btw do you have any doc to share on the SharedItemStateManager ?

touché ;) i am perfectly aware that a lot needs to be done in the documentation
area. we just didn't get around to do it. we'll improve it gradually
as time allows.
for the time being i suggest you search the mail archives. there were a 
couple of threads discussing/explaining jackrabbit's core design.

cheers
stefan

> 
> Stefan Guggisberg wrote:
> 
> >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
> >>
> >>
> >>
> >
> >
> >
> 
> 
> --
> Julien Viet
> JBoss Portal Lead Developer
> 
>

Mime
View raw message