Andrey, Do you prefer change behavior at runtime? I guess will be better have different methods for getting cache instance with fair and not fair sync.
On Mon, May 14, 2018 at 3:39 PM, Andrey Gura <ag...@apache.org> wrote: > +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 :) > >> > > >> >
