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: Consistency aka Isolation Level (was: OAK-638 Avoid branch/merge for small commits)
Date Wed, 06 Mar 2013 08:27:06 GMT


On 6.3.13 8:16, Marcel Reutegger wrote:
> Hi,
>
>> 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.

Ack.

>
> 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().

Ack.

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

Legacy.

Michael

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

Mime
View raw message