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/10/07 09:04:27 UTC

[jira] [Commented] (OAK-3439) MissingLastRevSeeker potential race condition acquiring the lock

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

Marcel Reutegger commented on OAK-3439:
---------------------------------------

IIUC, this is not backward compatible. The new code would not be able to acquire a lock on existing entries in the cluster nodes collection.

A new condition sounds better to me.

> MissingLastRevSeeker potential race condition acquiring the lock
> ----------------------------------------------------------------
>
>                 Key: OAK-3439
>                 URL: https://issues.apache.org/jira/browse/OAK-3439
>             Project: Jackrabbit Oak
>          Issue Type: Task
>          Components: core, rdbmk
>            Reporter: Julian Reschke
>            Assignee: Julian Reschke
>         Attachments: OAK-3439.diff, OAK-3439.diff, OAK-3439.diff
>
>
> {code}
>             // This approach has a race condition where two different cluster
>             // nodes
>             // can acquire the lock simultaneously.
>             UpdateOp update = new UpdateOp(Integer.toString(clusterId), true);
>             update.set(ClusterNodeInfo.REV_RECOVERY_LOCK, RecoverLockState.ACQUIRED.name());
>             store.createOrUpdate(Collection.CLUSTER_NODES, update);
>             return true;
> {code}
> It would be good if could harden this, however it seems that the conditions in UpdateOp only work on revision properties. [~mreutegg] WDYT?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)