+1 for fair async operations. But I don't like idea use withFairSync() method. We added xxxAsync() methods recently and withAsync() is deprecated.
I think we should just make methods are async in nature and provide ability of switching to the old behaviour using flag or property. On Fri, May 11, 2018 at 11:00 PM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > Vladimir, > > In general I agree, but I do get greatly *close-minded* (pun intended) > whenever users' code that worked for the past several years all of a sudden > gets deadlocked after an upgrade. Making this feature optional is even > worse and more confusing. In this case the best action is no action at all. > > BTW, would be interesting to find out how Oracle async driver behaves in > this case. > > D. > > > > > > On Fri, May 11, 2018 at 8:29 PM, Vladimir Ozerov <voze...@gridgain.com> > wrote: > >> Guys, >> >> To build a great product we should be open minded and look to the future, >> not to the past. >> >> Dima raised very valid point - why async is not async? Current programming >> culture and demanding performance requirements pushes users towards >> reactive-style programming. I do not want my thread to ever be blocked. >> Instead, I want to send a number of concurrent commands and optionally >> subscribe to final result. So trully async API makes total sense to me. >> >> But personally, my primary interest in this area is SQL. Oracle is >> preparing new async driver. ADBA - async database access. It was presented >> on recent JavaOne [1]. It is under active development right now - juse >> weave through the mailing list [2]. Some prototypes are already there [3]. >> PostgreSQL community even started adopted it [4]! >> >> I am not pushing for immediate actions, but at least we should understand >> which way the wind is blowing. As a mid-term goals I would propose to >> finally remove thread ID from our PESSIMISTIC transactions to allow for >> suspend/resume in different threads. And as a next step I would think on >> adopting async cache and SQL APIs. >> >> Vladimir. >> >> [1] >> http://www.oracle.com/technetwork/database/application-development/jdbc/ >> con1491-3961036.pdf >> [2] http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/ >> [3] https://github.com/oracle/oracle-db-examples/tree/master/java/AoJ >> [4] https://github.com/pgjdbc/pgjdbc/issues/978 >> >> On Fri, May 11, 2018 at 9:48 PM, Dmitriy Setrakyan <dsetrak...@apache.org> >> wrote: >> >> > On Fri, May 11, 2018 at 7:46 PM, Dmitriy Govorukhin < >> > dmitriy.govoruk...@gmail.com> wrote: >> > >> > > I will edit IGNITE-8475, and remove all part that belong to the public >> > api. >> > > Is it acceptable for you? >> > > >> > >> > Everything is acceptable, as long as the public API is safe :) >> > >>
