You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Marcel Reutegger (JIRA)" <ji...@apache.org> on 2015/09/02 14:24:45 UTC

[jira] [Updated] (OAK-3042) Suspend commit on external conflict

     [ https://issues.apache.org/jira/browse/OAK-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcel Reutegger updated OAK-3042:
----------------------------------
    Labels: resilience  (was: performance)

> Suspend commit on external 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
(v6.3.4#6332)