can I assume that this data is at least as current as the last write committed on the node where this watch is triggered Yes. Though, because watches are serialized, there may be additional changes downstream waiting to execute.
Ultimately I am trying to understand if I can reason about the data that is being passed in the CuratorEvent to processBackgroundResult. The important thing to understand is that you are getting a view at a moment in time. ZooKeeper is not a transactional system therefore you you cannot assume that the current view is the most recent state. -JZ On February 19, 2015 at 1:42:13 AM, Ray Jenkins ([email protected]) wrote: Hi All, I have a question about NodeCache's and NodeCacheListeners. I have read the documentation that states, "it's not possible to stay transactionally in sync. Users of this class must be prepared for false-positives and false-negatives. " It makes sense to me that if I query the NodeCache via a getCurrentData() call the cache may not be up to date with the leader, but I'm trying to understand how this pertains to the use of notifications via a NodeCacheListener. Are there any guarantees that can be made about the state of the NodeCache when a NodeCacheListener is notified, for example, considering the following code. this.nodeCacheListener = new NodeCacheListener() { @Override public void nodeChanged() throws Exception { nodeCache.getCurrentData().getData() } } this.nodeCache.getListenable().addListener(nodeCacheListener); this.nodeCache.start(true); When nodeChanged() is called and I examine the contents of nodeCache in the callback, can I assume that this data is at least as current as the last write committed on the node where this watch is triggered or is it possible that the nodeCache contains an even earlier view of this znode's data? From looking at the code it appears curator issues a read call after the watch is triggered and passes that result in a CuratorEvent to processBackgroundResult, setNewData is then called on the cache updating the contents of the AtomicReference and if a Objects.equals comparison fails the listeners are notified. Ultimately I am trying to understand if I can reason about the data that is being passed in the CuratorEvent to processBackgroundResult. If that data is the result of a read request issued to any node in the cluster, it is possible that the result was issued by a node that was not part of the quorum that accepted the write that triggered the watch, therefore the local node could be in sync with the leader but the cache could still be out of sync? Or is that read indicative of the local state of the node after a write has been committed? I don't see sync() called anywhere in the curator code when issuing a read, but is there any way to reason about the state of the NodeCache contents after a nodeChanged call, besides the fact that it may be stale? Thanks, -Ray
