jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Müller <thomas.muel...@day.com>
Subject Re: [jr3] Repository microkernel
Date Fri, 19 Feb 2010 10:12:12 GMT
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'.

- 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

Mime
View raw message