Hi,
Chetan discovered that in some cases spurious observation events would
be created when to sessions save concurrently. In a nutshell the problem
occurs since the current implementation of observation [1] expects a
linear sequence of revisions (per cluster node). However on Root.commit
there is a small race between rebasing and merging a branch: when
another session saves inside this time frame, its branch will have the
same base revision like that of the former session. In this case the
sequence of revisions is effectively non linear.
This problem was acknowledged and discusses earlier already in the
context of the commit hooks, which also might run against "the wrong"
base revision, and which might cause validation of global constraints.
The SegmentMk solves this by rebasing internally [2]. For the MongoMk
this was so far not deemed a problem [3].
Non of these approaches solves the problem for observation however. For
this case I currently see the following options:
1) Live with the spurious events
2) Tighten the contract of NodeStoreBranch.merge() to throw if a branch
is not rebased so the caller can rebase again and retry [4]
3) Tighten the contract of NodeStoreBranch.merge() such that for the non
trivial merge case it is obliged to do a merge commit first and commit
the rest of the changes on top of that. The return value should then
also include the merge conflict.
Michael
[1]
https://issues.apache.org/jira/browse/OAK-775?focusedCommentId=13641416&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13641416
[2] http://markmail.org/message/rdd5bljutuoendzl
[3] http://markmail.org/message/5vh6bk7ei32jgtbg
[4]
http://wiki.apache.org/jackrabbit/Conflict%20handling%20through%20rebasing%20branches
