jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2263) Cluster-aware lock expiration
Date Wed, 19 Aug 2009 07:16:14 GMT

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


Mime
View raw message