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 "Julian Reschke (JIRA)" <ji...@apache.org> on 2015/09/02 15:23:46 UTC

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

    [ 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
(v6.3.4#6332)