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 12:53:02 GMT
On 7/18/05, Marcel Reutegger <marcel.reutegger@gmx.net> wrote:
> Stefan Guggisberg wrote:
> > 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 know JBoss Cache in detail, but as far as I can see you may use
> it also with a flat data model. In the end it's an id anyway, whether it
> is a path or a simple string.

in theory, sure. i wonder how JBoss Cache (a tree cache by design) 
would perform with a flat data model of > 1 million sibling nodes....


> > 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.
> I still think that the contract for the SharedItemStateManager can be
> described in a very concise way and that also applies to the cache it is
> using. Once those contracts are described I don't see a reason why it
> shouldn't be possible to use another implementation.
> >>With the risk that someone will probably try to kill me on monday I
> >
> > ;)
> btw, that's not the reason why I'm working from home today.
> It's the U2 concert in zurich tonight ;)
> regards
>   marcel

View raw message