jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tobias Bocanegra" <tobias.bocane...@day.com>
Subject Re: Next Generation Persistence
Date Mon, 02 Apr 2007 07:12:36 GMT
hi jukka,
good work. very nice draft! i was working on a similar idea of a new
persistence model which went a bit further in some detailes and was
much alike how subversion stores it's content [0].
i see 2 additional fundamental paradigms that a persistence layer
should be based on:
1. copies must be very cheep (and just recorded as reference)
2. multiple (or all) workspaces must be able to live on the same
'persistence tree'

the first point basically describes a 'copy be reference'. this allows
very fast implementations of copy, checkin, restore, etc. the second
paradigm allows very fast inter-workspace operations, like clone,
copy, etc.

regards, toby

[0] http://subversion.tigris.org/design.html#server.fs.struct

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
>


-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---

Mime
View raw message