AsynchronousZookeeper

Asynchronously gets the children of the node specified by the given path.

Asynchronously creates a new node at the given path.

If a ''sequential'' disposition is provided in disp, then path is appended with a monotonically increasing sequence, thus guaranteeing that all sequential nodes are unique with path as their prefix.

Asynchronously deletes the node specified by the given path.

Asynchronously determines the status of the node specified by the given path if it exists.

Asynchronously gets the data and status of the node specified by the given path.

Asynchronously gets the ACL and status of the node specified by the given path.

Asynchronously sets the data for the node specified by the given path.

Asynchronously sets the ACL for the node specified by the given path.

Returns an asynchronous client in which operations implicitly attach the specified watch function.

The partial function fn is invoked when a watch is triggered or the session state changes. This method is typically used in a transient manner to introduce a watch function prior to performing a watchable ZooKeeper operation.

Example:

val zk = AsynchronousZookeeper(config)
val future = zk watch {
 case e: NodeEvent => ...
 case e: StateEvent => ...
} get "/foo"
...
future onSuccess {
 case (data, node) => ...
}
future onFailure {
 case e: NoNodeException => ...
}

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''.