Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of stefan.guggisberg@gmail.com
 designates 66.249.92.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=HWu68C+NPqXi5QkIjTTEMEy+eyduGN/u/FMDiWW4Ht2BjGDIOcD7/KrwSDrIL4AaD4CDnVeCHWiAKrk5ey7mepY/yy8iwSCFNKj5FWtRvIr9W44DQl5wl/9/+fQxNn5yKcDFho7XH4SmwbLX80TqsoOdWJRwcrpWNAd6E4/7s8o=
Message-ID: <90a8d1c00704050200g1a47201cxa5b57675c8a6f817@mail.gmail.com>
Date: Thu, 5 Apr 2007 11:00:51 +0200
From: "Stefan Guggisberg" <stefan.guggisberg@gmail.com>
To: dev@jackrabbit.apache.org
Subject: Re: Next Generation Persistence
In-Reply-To: <510143ac0704011237n46548326p38d08b6b46c6fb50@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <510143ac0704011237n46548326p38d08b6b46c6fb50@mail.gmail.com>

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.

cheers
stefan

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
>