You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Jukka Zitting (JIRA)" <ji...@apache.org> on 2009/08/18 17:19:14 UTC
[jira] Created: (JCR-2263) Cluster-aware lock expiration
Cluster-aware lock expiration
-----------------------------
Key: JCR-2263
URL: https://issues.apache.org/jira/browse/JCR-2263
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: clustering, jackrabbit-core, locks
Reporter: Jukka Zitting
Priority: Minor
The current lock expiration mechanism is only able to expire locks on the cluster node where they were first added. This avoids nasty race conditions, but hides the expiration time (getRemainingTime) from other cluster nodes and breaks expiration of the lock if the originating cluster node is removed from the cluster.
It would be nice to have a good cluster-wide lock expiration mechanism that doesn't end up with all cluster nodes trying to unlock expired locks at the same time.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2263) Cluster-aware lock expiration
Posted by "Thomas Mueller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744936#action_12744936 ]
Thomas Mueller commented on JCR-2263:
-------------------------------------
What if the expiration time depends on the cluster node id? So expiration time is 1 second longer on cluster node 1, 2 seconds longer on cluster node 2, and so on. Or randomly choose the additional time to wait.
> Cluster-aware lock expiration
> -----------------------------
>
> Key: JCR-2263
> URL: https://issues.apache.org/jira/browse/JCR-2263
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: clustering, jackrabbit-core, locks
> Reporter: Jukka Zitting
> Priority: Minor
>
> The current lock expiration mechanism is only able to expire locks on the cluster node where they were first added. This avoids nasty race conditions, but hides the expiration time (getRemainingTime) from other cluster nodes and breaks expiration of the lock if the originating cluster node is removed from the cluster.
> It would be nice to have a good cluster-wide lock expiration mechanism that doesn't end up with all cluster nodes trying to unlock expired locks at the same time.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.