问题
Is there any facility in the Apache Curator lock recipes (or lower-level ZooKeeper) for auto-releasing locks that have exceeded some TTL? If not, is there a best practice for dealing with that? I see that Curator automatically releases locks in the case of the client connection being lost, which is nice...and the timeout on lock acquisition is also helpful.
I'm wondering to what degree I need to protect my system by making a recurring job that looks for locks that have been around to long and manually releasing them. Would I do that by having my separate process directly delete the relevant ZNode?
回答1:
Curator's locks are implemented using EPHEMERAL znodes. So, if the lock holder becomes unstable in some way, ZooKeeper should automatically release the lock. If you're looking for a way to revoke locks held by other processes, some of Curator's lock recipes have a cooperative revoking facility. Other than that, deleting a lock from underneath a process seems like it would cause tremendous instability. I can't think of a good reason to do it.
(note: I'm the main author of Curator)
回答2:
FYI - this is 2 years later. I've written and have had accepted TTL Nodes for ZooKeeper (which, of course, Curator will support). It's in master now and will be in a future release of ZooKeeper and Curator.
https://issues.apache.org/jira/browse/ZOOKEEPER-2169
来源：https://stackoverflow.com/questions/27113914/apache-zookeeper-curator-time-to-live-on-locks