On 7.3.13 11:08, Marcel Reutegger wrote:
Hi,
I was referring to problem a, which is about validators and other
commit hooks not being a part of the underlying MK-level merge
operation and thus for example not always catching things like
duplicate UUIDs being introduced or hard references being broken (i.e.
repository invariants that span more than one node). This issue also
affects the MongoMK implementation, though it's yet unclear how
important addressing it is in practice. For some deployments it may
well be a hard requirement.
this is what I tried to describe in
http://jackrabbit.markmail.org/thread/5vh6bk7ei32jgtbg
the MicroKernel only provides snapshot isolation, while a NodeStore
implementation could also provide serializable snapshot isolation.
as mentioned before, I think snapshot isolation is just fined because
in most cases it is sufficient and allows for increased concurrency. for
the cases where more consistency guarantees are needed, like
unique UUIDs and hard references we should implement the
validators accordingly and e.g. use a technique like materializing the conflict.
I think a source of misunderstanding here is the interpretation of
serializable snapshot isolation within our immutable tree hierarchy:
strictly speaking every two commits conflict in such a setting since the
root node always changes. (We even experienced this with the index
update, which had exactly this effect). However I think your idea here
is to *not* count such conflicts and just have them merged. Similarly
as I brought up earlier: http://markmail.org/message/5vh6bk7ei32jgtbg
So IIUC, with such an approach branches wouldn't need to rebase in the
first place but just commit/merge. If there happens to be a conflict,
branches would rebase then and retry the commit/merge. Finally those who
need the stronger guarantee of serializable snapshot isolation could
e.g. use the technique of materialising the conflict.
Michael
regards
marcel
