10

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?

Scott Feinstein
  • 159
  • 1
  • 6

2 Answers2

11

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)

Randgalt
  • 2,907
  • 1
  • 17
  • 31
  • Thanks for the reply! Was hoping you'd see this and I've appreciated your other SO repsonses. Definitely aware of the automatic handling of a ZK client that loses its connection, and the cooperative revoking. Maybe I'm being too paranoid but I'm using ZK / Curator as an implementation detail of a library that does distributed locking. No control over the code that executes while a lock is held. I suppose I can abstract out the cooperative revoking aspect and therefore have a way of dealing with misbehaving client code. Thanks for the reply. – Scott Feinstein Nov 28 '14 at 18:53
3

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

Randgalt
  • 2,907
  • 1
  • 17
  • 31