The
write
operations in ZooKeeper are atomic and durable. There is the guarantee of a successful write
operation if it has been written to persistent storage on a majority of ZooKeeper's servers. However, the eventual consistency model of ZooKeeper permits reads to log the latest state of the ZooKeeper service, and the sync
operation allows a client to be up-to-date with the most recent state of the ZooKeeper service.
The read
operations in znodes, such as exists
, getChildren
, and getData
, allow watches to be set on them. On the other hand, the watches triggered by znode's write
operations, such as create
, delete
, and setData
ACL operations do not participate in watches.
The following are the types of watch events that might occur during a znode state change:
A watch event's type depends on the watch and the operation that triggered it. Some crucial information about how the three main operations have event-generating actions is shown in this table:
Operation |
Event-generating Actions |
---|---|
| |
|
A child of a znode is created or deleted, or the znode itself is deleted |
|
A watch
event includes the path of the znode where the event was generated. Thus, a client can find a znode creation and deletion for the NodeCreated
and NodeDeleted
events through the inspection of the path to the znode. To discover which children have changed after a NodeChildrenChanged
event, the operation getChildren
has to be called to retrieve the new list of children. Similarly, in order to discover the new data for a NodeDataChanged
event, getData
has to be called.
ZooKeeper provides a set of guarantees from its data model perspectives and watch infrastructure built on top of it, which enables the easy, fast, and scalable building of other distributed coordination primitives:
3.145.83.150