Well, if you are locking member IDS that are generated strings that will never be reused, the best you can do right now is clean those up after a period of time.
If, on the other hand, your member IDs are meaningful, it's likely you will want to reuse these locations in the future when you need to get another lock on this member. The overhead for a node in ZK is very very low, so unless you are generating a ton of these nodes that you then never use again and never clean up, it's not likely to be too much of a problem. We have discussed allowing "cleanup" type paths that will delete themselves when there are no child nodes. See: https://issues.apache.org/jira/browse/ZOOKEEPER-723 C -----Original Message----- From: Jordan Zimmerman [mailto:[email protected]] Sent: Tuesday, September 20, 2011 3:38 PM To: [email protected] Subject: Lock recipes and the lock path When writing the lock recipes for ZK, there is the potential for path garbage to build up. For example, imagine you are writing a lock for some kind go member ID. You'd have a base path for the locks (say "/locks/members") and then append the member ID to get locks on it. Thus, you'd end up with "/locks/members" building up paths, one for each member ID. How can you safely clean up the path for each member ID lock? There doesn't seem to be an atomic way to do it. If one process is cleaning up for example "/locks/members/12345", it can't be sure than another process might need to get a lock on that member ID. I.e. There's never a safe point to delete "/locals/members/12345". -JZ
