jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomek Rękawek (JIRA) <j...@apache.org>
Subject [jira] [Commented] (OAK-6425) Make the CompositeNodeStore thread-safe
Date Thu, 06 Jul 2017 16:27:00 GMT

    [ https://issues.apache.org/jira/browse/OAK-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16076833#comment-16076833

Tomek Rękawek commented on OAK-6425:

OK, how about synchronising only the merge() method? It'd help with the issue described in
the second bullet. Also, the clients will be able to call the getRoot() even during the merge().

The first bullet doesn't need any remedy, as the issue will only occur in a multiple RW case.

The efforts to support multiple RW will be track elsewhere. Just one question, [~mduerig]

bq. I wouldn't do this as supporting multiple rw stores is an entirely different story and
can't be done just in passing. To ensure our constraints we would need some sort of ACP (e.g
2PC) here. A simple lock won't do.

I was thinking about this a bit. How would you reverse the already applied changes if some
node stores fails on the merge? Keep the reference to the root NodeState and merge it back?
Or not a reference but a checkpoint? Or maybe introduce new method: {{NodeStore#restore(String

> 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

View raw message