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] MVCC
Date Mon, 08 Mar 2010 13:37:36 GMT

>> Relational databases don't usually persist all (intermediate)
>> versions, just the committed version. I don't think that copy-on-read
>> is a good idea. If we use append-only storage, in theory all old
>> versions are available, but indexing those is problematic.
> not necessarily. the current implementation in jackrabbit already
> supports quite some of these features. you can keep an index reader
> open while the index is updated, which basically gives you read-only
> multi-versioning. it would even be possible to go back in time by
> keeping old commit points. basic support for this is already
> implemented.

I didn't mean the Lucene index. I mean indexing the node position in
an append only storage (where is the node x version y stored in the
persistence manager). Currently Lucene is not used for that (and it

For append-only storage, probably the the easiest way to index old
versions is to persist a new root node for each transaction (like
CouchDB does). In each node, store the direct pointer (absolute or
relative file id / position) to all child nodes. In that case, no
separate index is required. However, I don't think we should *require*
that all persistence managers work like this. We should allow
append-only storage, but not require it.


View raw message