[
https://issues.apache.org/jira/browse/OAK-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582130#comment-13582130
]
Michael Dürig commented on OAK-638:
-----------------------------------
bq. As far as I can see the H2MK does not strictly implement the conflict
handling as you outlined for the merge case.
Right. That's why I consider (and I mentioned this before) this issue a
premature optimisation. We need to get conflict handling right first. Then we
can talk about making it fast.
bq. So, what if we change the implementation to fail fast when the
branchRevisionId does not match the current head revision?
My take on this is still: branch, rebase, fast forward merge. If the last
operation fails, try again. This does not lead to contention since all conflict
handling takes place on private branches thus not blocking other operations. It
does have an impact on performance though when the system is under a high load
since it might lead to additional retries then. But I consider this a different
problem which we should tackle through different means. Conflict handling on
private branches is separable so it scales horizontally and load can be
balanced and/or scheduled through a scheduler as you proposed in said thread.
bq. ...distinguish different levels of consistency when it comes to conflict
handling.
This has been observed a long time ago already. See
http://wiki.apache.org/jackrabbit/Transactional%20model%20of%20the%20Microkernel%20based%20Jackrabbit%20prototype
This is why we came up with the commit hooks, which separate the concerns of
conflict detection (what you call structural consistency) and conflict
resolution (what you call semantic consistency).
bq. To avoid creating the branch when a rebase is requested...
as said, I wouldn't avoid it but rather embrace it.
bq. ... we'd have to again implement the rebase in memory in KernelNodeStore,
with all the conflict handling
which often is the nature of optimisation: specialisation.
> Avoid branch/merge for small commits
> ------------------------------------
>
> Key: OAK-638
> URL: https://issues.apache.org/jira/browse/OAK-638
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Reporter: Marcel Reutegger
> Priority: Minor
> Attachments: OAK-638.patch
>
>
> The branch/merge features on the MicroKernel were initially introduced to
> stage changes of large commits. Currently oak-core creates a branch even for
> small changes like updating a property. I think this introduces quite some
> overhead for scenarios with highly concurrent updates. E.g. think of a
> twitter like application or a forum with comments. Well, basically user
> generated content. These update tend to be rather small (couple of nodes) but
> frequent and concurrent.
> Right now oak-core always does:
> - MK.branch()
> - MK.commit() to branch
> - MK.merge()
> For small commits, it ideally should do:
> - MK.commit() to trunk
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
