Hi, I mean you have to check the result of "sync" to "read" up to date view.
The "Consistency Guarantees" section in ZooKeeper Internals[1] explains better than. [1]: https://zookeeper.apache.org/doc/r3.9.3/zookeeperInternals.html Best, Kezhu Wang On Mon, Mar 31, 2025 at 9:42 PM David Smiley <[email protected]> wrote: > > > So does "read(/a)" after "sync". > > Can you clarify what you are trying to say there? > I know there is no quorum-read as a single operation but what about the > pairing of sync + read ? > > I'm looking at: > https://zookeeper.apache.org/doc/r3.9.3/zookeeperProgrammers.html > > Sometimes developers mistakenly assume one other guarantee that ZooKeeper > > does *not* in fact make. This is: * Simultaneously Consistent > > Cross-Client Views* : ZooKeeper does not guarantee that at every instance > > in time, two different clients will have identical views of ZooKeeper data. > > Due to factors like network delays, one client may perform an update before > > another client gets notified of the change. Consider the scenario of two > > clients, A and B. If client A sets the value of a znode /a from 0 to 1, > > then tells client B to read /a, client B may read the old value of 0, > > depending on which server it is connected to. If it is important that > > Client A and Client B read the same value, Client B should call the > > *sync()* method from the ZooKeeper API method before it performs its > > read. So, ZooKeeper by itself doesn't guarantee that changes occur > > synchronously across all servers, but ZooKeeper primitives can be used to > > construct higher level functions that provide useful client > > synchronization. (For more information, see the ZooKeeper Recipes > > <https://zookeeper.apache.org/doc/r3.9.3/recipes.html>. > > > > On Mon, Mar 31, 2025 at 3:03 AM Kezhu Wang <[email protected]> wrote: > > > Hi, > > > > There are networks between client and server. > > > > > Maybe you are saying sync would asynchronously > > > fail... okay but then wouldn't the subsequent read fail? > > > > It is possible that "sync" is lost and "read" is delivered after network > > repair. > > > > > If it wouldn't... well that's a shame; what a confusing API! My goal (of > > course) is to make > > > a specific read operation a quorum operation. > > > > From api semantics, "sync" is not much different than "write". > > "read(/a)" could fail or get outdated value or updated value after > > "write(/a)" failure. So does "read(/a)" after "sync". > > > > There is no quorum-read currently. Besides, ZOOKEEPER-22[1] never > > delivered. > > > > [1]: https://issues.apache.org/jira/browse/ZOOKEEPER-22 > > > > Best, > > Kezhu Wang > > > > On Mon, Mar 31, 2025 at 12:57 PM David Smiley <[email protected]> wrote: > > > > > > I could see how the asynchronous variant has value, but it'd require a > > > callback that sets a flag, like with an AtomicBoolean. Basically, submit > > > it, then do the read, *then* check that the boolean is true. If it > > isn't, > > > consider the read stale and try again (or throw). This way we don't wait > > > on the sync call to finish for the common code-path. > > > > > > On Sun, Mar 30, 2025 at 11:27 PM David Smiley <[email protected]> > > wrote: > > > > > > > Thanks for explaining things. I'll just use "/" then :-) > > > > > > > > If sync() fails, the code I have in mind would simply fail as well > > (since > > > > the subsequent read wouldn't even be reached), which is not a > > > > misleading/false result. Maybe you are saying sync would > > asynchronously > > > > fail... okay but then wouldn't the subsequent read fail? If it > > wouldn't... > > > > well that's a shame; what a confusing API! My goal (of course) is to > > make > > > > a specific read operation a quorum operation. It's too bad there > > isn't a > > > > *clear* way to do that correctly. > > > > > > > > On Sat, Mar 29, 2025 at 11:12 PM Kezhu Wang <[email protected]> wrote: > > > > > > > >> Hi, > > > >> > > > >> Currently, "path" has no meaning in "ZooKeeper.sync()". > > > >> ZOOKEEPER-3414[1] proposes to throw "NoNodeException" when "path" does > > > >> not exist. But it is not delivered. I used to use "/". > > > >> > > > >> Regarding the "callback", it is crucial in asynchronous, as > > > >> "ZooKeeper.sync" could fail due to connection issues while following > > > >> reads could succeed after reconnection. ZOOKEEPER-4747[2] introduces a > > > >> synchronous version to ease the callback handle. > > > >> > > > >> [1]: https://issues.apache.org/jira/browse/ZOOKEEPER-3414 > > > >> [2]: https://issues.apache.org/jira/browse/ZOOKEEPER-4747 > > > >> > > > >> Best, > > > >> Kezhu Wang > > > >> > > > >> On Fri, Mar 28, 2025 at 9:38 PM David Smiley <[email protected]> > > wrote: > > > >> > > > > >> > The javadocs on ZooKeeper.sync() are extremely sparse; nobody would > > > >> > understand this by only looking at it. I've looked at the > > programmer's > > > >> > guide, which actually explains its use. The callback appears > > pointless? > > > >> > Does the semantics of "sync" apply only to reading the path and its > > > >> > children list, or does it apply recursively to descendants beneath > > this > > > >> > path? > > > >> > > > > >> > ~ David Smiley > > > >> > Apache Lucene/Solr Search Developer > > > >> > http://www.linkedin.com/in/davidwsmiley > > > >> > > > > > >
