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: Next Generation Persistence
Date Thu, 05 Apr 2007 09:00:51 GMT
hi jukka

nice draft! i like the approach (using MVCC in jackrabbit's core). while the
draft might be a bit overenthousiastic wrt the benefits the proposed model
is certainly worth a serious evaluation. i am pretty confident that the pro's
will clearly outweigh the con's in the end. the best way to identify the issues
of the proposed model-change would IMO be to start work on a prototype.

IMO the major challenge will be read performance.


On 4/1/07, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
> Based on some idle thinking I've written up a proposed model for next
> gneration persistence in Jackrabbit. Instead of trying to explain the
> whole idea in an email I've written a web page (with diagrams!) to
> describe the model in more detail. You can find the model description
> at http://jackrabbit.apache.org/dev/ngp.html (it's not linked in the
> menu).
> To summarize, the model I'm proposing brings a heavily abstracted
> persistence layer up as the central focus point of the entire
> repository architecture. The persistence model I'm proposing has
> implications all the way to things like clustering implementation,
> node type management, and session handling. In fact it would
> revolutionarize almost all parts of Jackrabbit core. ;-)
> On the other hand, instead of seeing the proposed model as a
> revolution, it could be seen simply as a way to raise the prominence
> of the ChangeLog class over the ItemState  model. Currently ItemStates
> are the central concept in Jackrabbit and the ChangeLog class is just
> a way to group together a set of ItemState changes. In the model I'm
> proposing the ChangeLog, or a revision, would instead become the
> central concept that governs not only read and write operations but
> also things like transactions and observation to a much greater degree
> than it does today.
> There are a number of open issues with the proposal, especially how to
> make it perform well and not use too much disk space, but I feel that
> the model is interesting enough for serious consideration and perhaps
> even early prototyping. I'm especially interested in hearing your
> thoughts on how feasible you think such a model would be and what
> potential pitfalls I may have missed. Any other comments and ideas are
> also welcome.
> BR,
> Jukka Zitting

View raw message