jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <mreut...@adobe.com>
Subject RE: Consistency aka Isolation Level (was: OAK-638 Avoid branch/merge for small commits)
Date Wed, 06 Mar 2013 08:16:16 GMT

> My take on this was: when we rebase internally anyway, why not make this
> rebase available externally so branches could rebase themselves and thus
> make it easier for the commit later on? AFAICS the internal rebase would
> either have to be on something which pretty much resembles a private
> branch (optimistic locking) or would need to be synchronised for
> serialising concurrent commits. The latter would result in a very fat
> lock and is not what we want. FYI the H2 based Microkernel tries to
> implement commit without such a fat lock and fails. See OAK-532.

I don't think this is an implementation issue, but rather a design
problem as you noted in the discussion on the dev list referenced in
OAK-532 (http://markmail.org/message/4xwfwbax3kpoysbp)

Concurrent deletes of nodes must IMO fail for the reasons you
stated and the test you provided in OAK-532.

I think we should remove the example from the MK.commit()
JavaDoc and refer to the conflict definition of MK.rebase(). after
all this is how I understand your proposal [0] and implication
on MK.commit().

what is the reason MK.commit() explicitly says deleting a concurrently
deleted node must be merged?


[0] http://wiki.apache.org/jackrabbit/Conflict%20handling%20through%20rebasing%20branches

View raw message