AsynchronousWatchableZookeeper

Asynchronously gets the children of the node specified by the given path and additionally sets a watch for any changes.

The watch is triggered when one of the following conditions occur:

• the session state changes

Asynchronously determines the status of the node specified by the given path if it exists and additionally sets a watch for any changes.

The watch is triggered when one of the following conditions occur:

• the data associated with the node changes
• the node is created
• the node is deleted
• the session state changes

Asynchronously gets the data and status of the node specified by the given path and additionally sets a watch for any changes.

The watch is triggered when one of the following conditions occur:

• the data associated with the node changes
• the node is deleted
• the session state changes

Returns a view of this client in which operations are performed ''asynchronously''.

Closes the client connection to the ZooKeeper cluster.

A consequence of closing the connection is that ZooKeeper will expire the corresponding session, which further implies that all ephemeral nodes created by this client will be deleted.

Ensures that the value of a node, specified by the given path, is synchronized across the ZooKeeper cluster.

'''An important note on consistency''': ZooKeeper does not guarantee, for any given point in time, that all clients will have a consistent view of the cluster. Since reads can be served by any node in the cluster, whereas writes are serialized through the leader, there exists the possibility in which two separate clients may have inconsistent views. This scenario occurs when the leader commits a change once consensus is reached, but the change has not yet propagated across the cluster. Therefore, reads occurring before the commit has propagated will be globally inconsistent. This behavior is normally acceptable, but for some use cases, writes may need to be globally visible before subsequent reads occur.

This method is particularly useful when a ''write'' occurring in one process is followed by a ''read'' in another process. For example, consider the following sequence of operations:

• process A writes a value
• process A sends a message to process B
• process B reads the value

The assumption is that process B expects to see the value written by process A, but as mentioned, ZooKeeper does not make this guarantee. A call to this method before process B attempts to read the value ensures that all prior writes are consistently applied across the cluster, thus observing the write in process A.

Returns the session associated with ZooKeeper.

Note that the connection with ZooKeeper is established asynchronously, which means there is no implied guarantee that the session has connected nor will eventually connect at the time that an instance of this trait is created.

Returns a view of this client in which operations are performed ''synchronously''.