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.
Michael
