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 :) >
