Site icon DataFlair

ZooKeeper Watches – Features & Guarantees

ZooKeeper Watches

ZooKeeper Watches - Features & Guarantees

In our last ZooKeeper tutorial, we discussed ZooKeeper Locks. Also, there are various guarantees, with regard to watches in ZooKeeper, we will discuss them as well.

However, along with this, it guarantees there are some important points about  ZooKeeper Watches, we will also discuss them in detail.

So, let’s start ZooKeeper Watches.

What is ZooKeeper Watches?

In ZooKeeper, all of the read operations – getData(), getChildren(), and exists() – have the option of setting a watch as a side effect.

Defining ZooKeeper Watches, when the data for which the watch was set changes, a watch event (one-time trigger), sent to the client which set the watch. However, in this definition of a watch, there are three key points to consider, such as:

a. One-time trigger

When any change occurs in data, one watch event will be sent to the client. Let’s say the client will get a watch event for /znode1 if a client does a getData(“/znode1”, true) and later the data for /znode1 is changed or deleted.

However, it will not send any watch event unless the client performs another read which sets a new watch, if /znode1 changes again.

b. Sent to the client

It simply means that an event is on the way to the client. However, it may not reach the client somehow, before the successful return code to the change operation reaches the client which initiated the change.

Asynchronously, ZooKeeper Watches send to ZooKeeper watchers. Also, a client will never see a change for which it has set a watch until it first sees the watch event, this is an ordering guarantee offered by ZooKeeper.

However, sometimes, the network may delay or also other factors may cause different clients to see watches and further return codes from updates at different times. Though we can say, different clients will have a consistent order is the key point of it.

c. The data for which the watch was set

It says in different ways we can change a node. Basically, that makes us think of ZooKeeper as maintaining two lists of watches. Those are Data ZooKeeper Watches and Child ZooKeeper Watches. To set data watches, getData() and exists() and to set child watches, getChildren(). 

However, both getData() and exists() gets the information about the node’s data. And,  getChildren() gets the list of children. Hence, successful setData() will trigger data watches to set the ZNode.

Locally, ZooKeeper servers which are connected to the client maintain the watches. Though it permits in order to set watches they are must lightweight.

Moreover, the watch will trigger for any session events, when a client connects to a new server. However, while disconnected from a server, watches will not receive.

But at the time when the client reconnects, any previously registered watches will trigger as well as reregistered as per requirement. Also, we can say this all occurs transparently.

Moreover, the watch can also be missed if the Znode is created and deleted while disconnected, then a watch for the existence of a ZNode not yet created will be missed.

What ZooKeeper Guarantees about Watches?

ZooKeeper maintains various guarantees, with regard to watches:

Things to Remember about Watches

So, this was all in Zookeeper Watches. Hope you like our explanation.

Conclusion

Hence, in this ZooKeeper watches tutorial, we have seen the whole about ZooKeeper Watches along with its features and important points. However, if any doubt occurs regarding ZooKeeper Watches, feel free to ask in the comment section.

Exit mobile version