Huh, interesting. I'd never heard about either R2DBC or ADBA. When libraries claim to be asynchronous or non-blocking, half of them just run all blocking calls in a background threadpool/FJPool and give you a nice "asynchronous" API for your "user code". While this might be good for convenience and pretty APIs, they often actually increase resource utilization (e.g elevate thread counts) and make them actually harder to manage! They're usually still 1 blocked thread per connection or inflight query.
"Real" asynchronous libraries use slightly more advanced facilities (epoll/nio/netty) to "batch" blocking IO calls and manage many more connections with a fixed 1 or 2 threads. One to two threads can send/receive on ALL sockets or connections efficiently and update all futures. I can't tell from those project pages which approach they are taking. I understand that Jooq will probably operate in a level agnostic to those details but when talking about Flow or CompletableFuture API's it sorta emphasizes API ecosystems and doesn't seem to address implementation/architecture. Thanks! On Friday, June 21, 2019 at 10:30:26 AM UTC-7, Lukas Eder wrote: > > Hi Marshall, > > Thank you very much for your message. > > jOOQ 3.12 (shipping in June/July 2019) will finally have ResultQuery<R> > extend Publisher<R> and a new RowCountQuery type will extend > Publisher<Integer> (both from reactive streams and JDK 9 Flow). The > implementation is still JDBC bound, and thus blocking. In jOOQ 3.13, we'll > finally look into abstracting over JDBC and binding to R2DBC and possibly > ADBA. It was not reasonable to do this before at least R2DBC (which I > estimate will be wildly more popular than ADBA) stabilised. They're > stabilising now and are planning to release 1.0.GA in Q3/Q4 2019. > > I've been much involved on the lists and behind the scenes with both R2DBC > and ADBA to make sure all the more remote edge cases of JDBC usage, > including e.g. SQL Server's mixed out parameter / result set / update count > / exception streams can be supported also in the reactive world, where this > makes even more sense than in JDBC. > > In order to bind to R2DBC, we'll probably have to abstract away quite a > bit of internals that are currently directly bound to JDBC. I can't say how > much effort this will be, exactly, nor if we can cover the entirety of > JDBC's scope, or jOOQ's current feature set. But I'm positive, we'll get a > working demo out about when R2DBC goes live. > > Notice also that reactive != asynchronous. There will be additional work > in retrofitting jOOQ's current fetchAsync() and executeAsync() > implementations to work with the reactive API. What this means exactly, I > cannot say yet. > > I hope this clarifies our roadmap a bit. Do note that for the time being, > you will always be able to manually write the glue code between jOOQ and > whatever async/reactive driver you're using, by using Query.getSQL() and > Query.getBindValues(). > > Cheers, > Lukas > > On Thu, Jun 20, 2019 at 5:00 PM Marshall Pierce <[email protected] > <javascript:>> wrote: > >> Any idea when/if nonblocking i/o for db access will make percolate its >> way through enough of a standardization process that jooq will expose >> it? I'd love to be able to use jooq without having a threadpool around >> to do blocking i/o on. >> >> There's at least some activity on the mailing list ostensibly associated >> with getting ADBA done: >> http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/. Both pgadba >> and pgnio both seem to be in a holding pattern waiting for ADBA to firm >> up, though, and I think ADBA was last mentioned on the jooq blog on a >> 4/1 post. ;) >> >> What I need to do now (in Kotlin + coroutines): >> >> // toss the work into a thread pool for blocking i/o >> val result = withContext(Dispatchers.IO) { >> jooq.transactionResult { txn -> >> // run queries here >> } >> } >> >> API wise, it'd be sometimes convenient to have the callback provided to >> `transactionResult` be a suspending function for nicer integration with >> coroutines, but rearranging things to be based around CompletableFutures >> would be just about everything I want, and I could probably build a >> suspending helper function on top of that. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "jOOQ User Group" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jooq-user/e7a4c55d-1ec8-5bfe-4745-dc36432b019f%40mpierce.org >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/4e748430-0273-407f-b5fa-328f71b9ef0b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
