jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: Revision stability with new MongoMK
Date Wed, 06 Mar 2013 15:22:28 GMT

>Do you have estimates on the potential performance impact of this?

I think in performance and memory overhead would be minimal, unless there
is a massive number of cluster nodes. The revision number consists of
[timestamp|machineId] (similar to the MongoDB ObjectId; machineId is the
same as the cluster node id). Based on that, revisions from a certain
cluster node can be ordered by timestamp+counter. When detecting revisions
(by reading the write counter at the root node and traversing the tree)
that were written by another cluster node, older revisions from the same
cluster node don't need to be kept in memory individually, as they can be
sorted by timestamp. Because of that, each cluster node wouldn't have to
maintain a complete list of all revisions, but only a list of revision
groups (only the exceptions to the timestamp|machineId order). For example:

[r1000|1]-[r2000|1], [r1200|2]-[r1300|2], [r2001|1]-[r3000|1]

In that case, the revisions of cluster node 1 ([r1000|1]-[r2000|1])
happened before revisions of cluster node 2 ([r1200|2]-[r1300|2]) but
before later revisions of cluster node 1 ([r2001|1]-[r3000|1]).

An open question is whether this complexity is really needed, or if we
could just do what databases usually do (read committed isolation level by
default, instead of repeatable read).


View raw message