zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fournier, Camille F." <Camille.Fourn...@gs.com>
Subject RE: Lock recipes and the lock path
Date Tue, 20 Sep 2011 19:44:35 GMT
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:


-----Original Message-----
From: Jordan Zimmerman [mailto:jzimmerman@netflix.com] 
Sent: Tuesday, September 20, 2011 3:38 PM
To: user@zookeeper.apache.org
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

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


View raw message