jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: SegmentNodeStore merge operations
Date Thu, 07 Mar 2013 11:35:51 GMT

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.


> regards
>   marcel

View raw message