Menu
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?
866
Zookeeper Locks are fully distributed locks in ZooKeeper which are globally synchronous. However, globally synchronous means at any snapshot in time no two clients think they hold the same lock. Though these we can implement these locks by using ZooKeeper.
The Curator Framework is a high-level API that greatly simplifies using ZooKeeper. It adds many features that build on ZooKeeper and handles the complexity of managing connections to the ZooKeeper cluster and retrying operations.
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)
137
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
