[
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.
