jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: [jr3] Repository microkernel
Date Fri, 19 Feb 2010 15:03:15 GMT

On Fri, Feb 19, 2010 at 11:12, Thomas Müller <thomas.mueller@day.com> wrote:
> Hi,
> A agree with Marcel, the current Jackrabbit SPI it too high level.
>> it must be impossible to create inconsistent data using the micro-kernel API
>> - tree and referential integrity awareness
> +1. No more consistency check / fix. No more inconsistent index if the
> property-value-index is also part of the micro-kernel.
>> - long running transaction support
> I think 'large' transaction support is important, but it doesn't need
> to be very fast. I would avoid creating temporary files (persisting
> the cache). Instead, changes could be written to storage, but not
> committed.
> A few ideas (but I'm not convinced all of them are good ideas):
> - In memory, each node points to its (main) parent. If a node is in
> memory, then its parent is also.
> - Nodes are immutable (in memory, and on disk). Each change (or at
> least commit) will replace all parent nodes including the root node.
> - No change merging. Instead, use MVCC (when reading) and 'node level
> write locking'. As far as I know this is like most MVCC databases
> work. Actually we could use 'property level write locking'.

right, but that has the major drawback that we cannot write transient
modifications directly into the backend. unless we limit long running
transient-scoped changes with a timer. otherwise a transient
modification could easily hold up other sessions. besides, how would
you support node level write locks in a clustered environment?

I think there is no way around some change merging. I would try to
design something that works along the lines of a SCM system. before
you commit, do an update and merge external changes into your
modification, then commit. I think for most of the conflict scenarios
there are sensible resolutions that will work well in practice.


> - Support multiple persistence backends (database, file system,...).
> - Support two phase commit and distributed transaction at a very low
> level, so that it's very easy to distribute data to many storage
> backends.
> - Move operations are copy+delete internally (maybe reordering a node
> in the list of child nodes is also a move).
> - Subtrees that didn't change for a longer time are eventually
> persisted as one blob in the data store in a form that is compact and
> fast to read
> Regards,
> Thomas

View raw message