jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Reschke (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-3042) Suspend commit on conflict
Date Wed, 02 Sep 2015 13:23:46 GMT

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

Julian Reschke commented on OAK-3042:

This sounds like an improvement that would also be useful in 1.2 and 1.0...

> Suspend commit on conflict
> --------------------------
>                 Key: OAK-3042
>                 URL: https://issues.apache.org/jira/browse/OAK-3042
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core, mongomk
>            Reporter: Marcel Reutegger
>            Assignee: Marcel Reutegger
>              Labels: resilience
>             Fix For: 1.3.6
> A DocumentNodeStore cluster currently shows a conflict behavior, which
> is not intuitive. A modification may fail with a conflict even though
> before and after the conflict, the external change is not visible to
> the current session. There are two aspects to this issue.
> 1) a modification may conflict with a change done on another cluster
> node, which is committed but not yet visible on the current cluster node.
> 2) even after the InvalidItemStateException caused by the conflict, a
> refreshed session may still not see the external change.
> The first aspect is a fundamental design decision and cannot be changed
> easily.
> The second part can be addressed by suspending the commit until the external
> conflict becomes visible on the current cluster node. This would at least
> avoid the awkward situation where the external change is not visible after
> the InvalidItemStateException.
> The system would also become more deterministic. A commit currently goes
> into a number of retries with exponential back off, but there's no guarantee
> the external modification becomes visible within those retries. 

This message was sent by Atlassian JIRA

View raw message