Hi, On 2/15/07, Miro Walker <[EMAIL PROTECTED]> 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
