jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Building a Jackrabbit roadmap
Date Thu, 15 Feb 2007 18:24:06 GMT
Hi,

On 2/15/07, Miro Walker <miro.walker@gmail.com> wrote:
> On a similar topic, I think addressing JCR-672 and dealing with the
> deadlock problems in Jackrabbit once and for all :-) would be a great
> idea. This has been an ongoing problem for a long time now, but each
> attempt to address it seems to come to the conclusion that the work
> required is a bit too big and scary to do easily. Perhaps if we added
> it to a roadmap for a specific version, then we could bite the bullet
> and take it on?

I generally prefer to use features to drive the release plans rather
than the other way around, but you're right in that this is a serious
problem that needs to be solved rather sooner than later.

One high-level solution that I've been thinking about as a potential
way to both avoid extensive locking and to increase the level of
parallelism is to use multiversion concurrency control. MVCC is
especially attractive since it never blocks read operations, and would
even allow us to get rid of the in-memory transient space. Such a
change would however require massive refactoring of Jackrabbit
internals, so I'd only embark on such a mission if there's wide
consensus that it's actually something we should do. Having a couple
of long-time database experts around would also make me much more
confident of the success with such a change...

> On the topic of performance, one thing that I'd like to get included
> if possible (perhaps this flows from some of the JSR-283 versioning
> changes) is a model of versioning that doesn't duplicate all data
> between workspaces, but rather allows workspaces to store pointers
> into a central version history. This would vastly increase the
> performance of cross-workspace operations, a major headache for us.

Good idea! A related improvement would be to only store deltas of
successive versions in the version store.

BR,

Jukka Zitting

Mime
View raw message