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 Tue, 05 Mar 2013 13:00:31 GMT

On 5.3.13 12:57, Michael Dürig wrote:
>> Jukkas implementation of the conflict handling provides
>> Serializable Snapshot Isolation because it re-runs the hooks on
>> a rebased branch whenever a concurrent change is detected
>> before it merges. If we allow it to be more clever, we lose
>> the Serializable part of the isolation level. Though, I think that's
>> quite OK. See below.
>> With the MicroKernel the story is a bit different. E.g. the conflict
>> handling model allows the commit to internally rebase, but
>> without re-running the commit hooks. validation and changes
>> performed by the commit hook are already part of the JSOP.
>> This means the MicroKernel will exhibit 'write skew' and not
>> provide Serializable Snapshot Isolation. This was already described
>> a while ago by Michael [1].
> 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.

Just to further clarify, the approach where private branches are rebase 
and the merged into trunk is not too different from what the initial 
implementation of Microkernel.commit() (H2) tried to do: rebase and then 
merge. The difference is, that we can "take rebase out of the lock" if 
we perform it on a private branch.


View raw message