ZooKeeper - Hadoop: The Definitive Guide - page 745

Watchers are triggered only once. [ 144 ] To receive multiple notifications, a client needs to
reregister the watch. So, if the client in the previous example wishes to receive further no-
tifications for the znode's existence (to be notified when it is deleted, for example), it
needs to call the exists operation again to set a new watch.

There is an example in A Configuration Service demonstrating how to use watches to up-
date configuration across a cluster.

Operations

There are nine basic operations in ZooKeeper, listed in Table 21-2 .

Table 21-2. Operations in the ZooKeeper service

Operation Description

Creates a znode (the parent znode must already exist)

create

Deletes a znode (the znode must not have any children)

delete

Tests whether a znode exists and retrieves its metadata

exists

getACL , setACL Gets/sets the ACL for a znode

Gets a list of the children of a znode

getChildren

getData , setData Gets/sets the data associated with a znode

Synchronizes a client's view of a znode with ZooKeeper sync

Update operations in ZooKeeper are conditional. A delete or setData operation has
to specify the version number of the znode that is being updated (which is found from a
previous exists call). If the version number does not match, the update will fail. Up-
dates are a nonblocking operation, so a client that loses an update (because another pro-
cess updated the znode in the meantime) can decide whether to try again or take some oth-
er action, and it can do so without blocking the progress of any other process.

Although ZooKeeper can be viewed as a filesystem, there are some filesystem primitives
that it does away with in the name of simplicity. Because files are small and are written
and read in their entirety, there is no need to provide open, close, or seek operations.