ZooKeeper - Hadoop: The Definitive Guide - page 744

Ephemeral znodes
As we've seen, znodes can be one of two types: ephemeral or persistent. A znode's type is
set at creation time and may not be changed later. An ephemeral znode is deleted by
ZooKeeper when the creating client's session ends. By contrast, a persistent znode is not
tied to the client's session and is deleted only when explicitly deleted by a client (not ne-
cessarily the one that created it). An ephemeral znode may not have children, not even
ephemeral ones.
Even though ephemeral nodes are tied to a client session, they are visible to all clients
(subject to their ACL policies, of course).
Ephemeral znodes are ideal for building applications that need to know when certain dis-
tributed resources are available. The example earlier in this chapter uses ephemeral
znodes to implement a group membership service, so any process can discover the mem-
bers of the group at any particular time.
Sequence numbers
A sequential znode is given a sequence number by ZooKeeper as a part of its name. If a
znode is created with the sequential flag set, then the value of a monotonically increasing
counter (maintained by the parent znode) is appended to its name.
If a client asks to create a sequential znode with the name /a/b- , for example, the znode
created may actually have the name /a/b-3 . [ 143 ] If, later on, another sequential znode with
the name /a/b- is created, it will be given a unique name with a larger value of the counter
— for example, /a/b-5 . In the Java API, the actual path given to sequential znodes is com-
municated back to the client as the return value of the create() call.
Sequence numbers can be used to impose a global ordering on events in a distributed sys-
tem and may be used by the client to infer the ordering. In A Lock Service , you will learn
how to use sequential znodes to build a shared lock.
Watches
Watches allow clients to get notifications when a znode changes in some way. Watches are
set by operations on the ZooKeeper service and are triggered by other operations on the
service. For example, a client might call the exists operation on a znode, placing a
watch on it at the same time. If the znode doesn't exist, the exists operation will return
false . If, some time later, the znode is created by a second client, the watch is triggered,
notifying the first client of the znode's creation. You will see precisely which operations
trigger others in the next section.