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

Returns the children of the node specified by the given path.

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.

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.

Deletes the node specified by the given path.

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 status of the node specified by the given path if it exists.

Returns the data and status of the node specified by the given path.

Returns the ACL and status of the node specified by the given path.

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.

Sets the data for the node specified by the given path.

Sets the ACL for the node specified by the given path.

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

Atomically performs a set of operations, either committing all or none.

The set of operations are applied by ZooKeeper in sequential order. If successful, this method returns a Right containing a sequence of results that positionally correlate to the sequence of operations. Otherwise, it returns a Left similarly containing a sequence of problems.

Example:

val ops = CheckOperation("/foo", None) ::
          CreateOperation("/bar", Array(), ACL.EveryoneAll, Persistent) :: Nil
zk transact ops match {
  case Right(results) => ...
  case Left(problems) => ...
}

Returns a synchronous 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 = SynchronousZookeeper(config)
val (data, node) = zk watch {
  case e: NodeEvent => ...
  case e: StateEvent => ...
} get "/foo"