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 <[EMAIL PROTECTED]> 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
