[
https://issues.apache.org/jira/browse/OAK-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16076013#comment-16076013
]
Michael Dürig commented on OAK-6425:
------------------------------------
For the second bullet point brought forward I don't see a good and simple
enough solution. Ensuring mutual exclusion is the right thing to do from a
correctness POV. As an alternative to the current approach you could employ
optimistic locking and rebase and run the commit hooks again should someone
have committed in between. However this would only put more load on the system
at a point where it is already contended. This is *exactly* the same challenge
we faced in the segment node store implementation. We started with optimistic
locking and backed off to pessimistic locking soon afterwards.
> Make the CompositeNodeStore thread-safe
> ---------------------------------------
>
> Key: OAK-6425
> URL: https://issues.apache.org/jira/browse/OAK-6425
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: composite
> Reporter: Tomek Rękawek
> Assignee: Tomek Rękawek
> Fix For: 1.8, 1.7.4
>
>
> The CompositeNodeStore, unlike other *NodeStore implementations, is not
> thread safe (eg. two concurrent merge() invocations may leave the repository
> in inconsistent state).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
