Database Reference
In-Depth Information
In the Java API, all the asynchronous methods have
void
return types, since the result of
the operation is conveyed via a callback. The caller passes a callback implementation
whose method is invoked when a response is received from ZooKeeper. In this case, the
callback is the
StatCallback
interface, which has the following method:
public
void
processResult
(
int
rc
,
String path
,
Object ctx
,
Stat
stat
);
The
rc
argument is the return code, corresponding to the codes defined by
KeeperEx-
ception
. A nonzero code represents an exception, in which case the
stat
parameter
will be
null
. The
path
and
ctx
arguments correspond to the equivalent arguments
passed by the client to the
exists()
method, and can be used to identify the request for
which this callback is a response. The
ctx
parameter can be an arbitrary object that may
be used by the client when the path does not give enough context to disambiguate the re-
quest. If not needed, it may be set to
null
.
There are actually two C shared libraries. The single-threaded library,
zookeeper_st
,
supports only the asynchronous API and is intended for platforms where the
pthread
library is not available or stable. Most developers will use the multithreaded library,
zoo-
keeper_mt
, as it supports both the synchronous and asynchronous APIs. For details on
how to build and use the C API, refer to the
README
file in the
src/c
directory of the
ZooKeeper distribution.
SHOULD I USE THE SYNCHRONOUS OR ASYNCHRONOUS
API?
Both APIs offer the same functionality, so the one you use is largely a matter of style. The asynchronous
API is appropriate if you have an event-driven programming model, for example.
The asynchronous API allows you to pipeline requests, which in some scenarios can offer better through-
put. Imagine that you want to read a large batch of znodes and process them independently. Using the
synchronous API, each read would block until it returned, whereas with the asynchronous API, you can
fire off all the asynchronous reads very quickly and process the responses in a separate thread as they
come back.
Watch triggers
The read operations
exists
,
getChildren
, and
getData
may have watches set on
them, and the watches are triggered by write operations:
create
,
delete
, and
setData
. ACL operations do not participate in watches. When a watch is triggered, a
watch event is generated, and the watch event's type depends both on the watch and the
operation that triggered it:
