Our intention with sync at the time was to have an operation that in combination with a read gives us linearizable semantics. As it is discussed in the jira, if there is out-of-band communication, then a client can get a stale result for a read. The sync op was made async *only* because we wanted to have the operation open or ongoing while issuing the read. If the sync is synchronous, then it will have returned by the time you submit the read. Making the sync call asynchronous clearly doesn't prevent zookeeper from processing the sync before the read, but it has the advantage of not blocking the read which is the operation you're really interested in. Also, even if you're using the sync api for the core operations, you can still call sync asynchronously and it will have the same effect.
I don't see a strong reason for adding a synchronous sync, and we should really encourage the use of asynchronous sync and not have a synchronous version of sync, but let me know if I'm missing something important. -Flavio > On 07 Jun 2016, at 23:49, Marshall McMullen <[email protected]> > wrote: > > https://issues.apache.org/jira/browse/ZOOKEEPER-1167 > > On Tue, Jun 7, 2016 at 4:46 PM, Michael Han <[email protected]> wrote: > >> Hi devs, >> >> Currently ZooKeeper::sync() API only has an asynchronous version: >> >> public void sync(String >> < >> http://docs.oracle.com/javase/6/docs/api/java/lang/String.html?is-external=true >>> >> path, >> AsyncCallback.VoidCallback >> < >> https://zookeeper.apache.org/doc/r3.5.1-alpha/api/org/apache/zookeeper/AsyncCallback.VoidCallback.html >>> >> cb, >> Object >> < >> http://docs.oracle.com/javase/6/docs/api/java/lang/Object.html?is-external=true >>> >> ctx) >> >> Asynchronous sync. Flushes channel between process and leader. >> >> Given that all other existing APIs have both sync and async version, should >> we also have a synchronous version of the "sync()" API? >> >> -- >> Cheers >> Michael. >>
