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)