Optionally support ZNodes of type 'container' when creating locks

[mstyne]

Hello again @Gutza!

When a lock, say:

/mstyne/test/lock-0000000001

is released, the parent node

/mstyne/test

is left behind. Is there some reason for doing this that I might not be aware of as a non Zookeeper-guru? Would it be inadvisable to allow for an option to remove the parent node as well? Would using an ephemeral node for locking purposes be a Bad Idea?

If this seems like it might be a reasonable addition to you, I'll see about putting together a pull request.

Let me know what you think, and thanks.

Mike

[Gutza]

It could be optionally released, but I think for most practical use cases it would be desirable to keep it – I tend to associate parent nodes with database records, e.g. /myProject/userProfile22/lock-0000000001; sooner or later I'll need to lock that user profile again, so I don't think it's worth deleting and recreating those. Also, if you're considering deleting empty parent nodes it would make sense to consider deleting empty grandparent nodes, grand-grandparent nodes and so on (at least for completeness); I'm not sure how much usefulness could be extracted from that (but of course, YMMV).

Using ephemeral nodes for locking is a Good Idea (tm) – in fact, NOT using ephemeral nodes is a Bad Idea. When your execution thread dies because of an exception you want to make sure your lock dies as well – and you can only ensure that reliably with ephemeral nodes. Otherwise you risk having your thread die and your lock persist indefinitely.

Best,
Bogdan

[mstyne]

Didn't mean to close this; thanks for the insight, Bogdan!

[Gutza]

No worries – exceptions happen. :-)

[mstyne]

Laziness prevails!

https://issues.apache.org/jira/browse/ZOOKEEPER-2163

I suppose once this makes it into a release, it can be optionally be used as a node type when creating a lock.

[mstyne]

Looks like this will be in Zookeeper 3.5.1.