On Fri, Jun 21, 2019 at 8:55 PM Kevinjeet Gill <[email protected]> wrote:
> Huh, interesting. I'd never heard about either R2DBC or ADBA. > I'm glad you did, now :) > 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. > Well, here are my 2 cents: 1. Those APIs are far from pretty or convenient. They are at best useful. Compared to classic, synchronous, (and even imperative) code, they create a million lines of boiler plate, and difficult to understand indirections, which are hard to debug, especially when following the reactive model. "Why isn't my code executed?" Well good luck finding out which completely unrelated part of your very complex stream had an excess "Flux.distinctUntilChanged()" in it, that blocked all consumer updates. 2. The ugly truth in most cases is that those blocking calls are hardly a problem, even within a reactive stream, because the use-case of going asynchronous might have been overrated, at least in the domain of DB interactions in most ordinary applications. At some point, we'll get this "right", even in Java. And I have a lot more hopes for project Loom than for these API driven solutions, because solving asynchronicity and reactiveness with APIs alone is going to clutter client code with tons of uninteresting and difficult to reason about infrastructure code. This is also something Oracle is thinking about. Should they push ADBA and make it *both* asynchronous (CompletionStage) and reactive (Flow), or should they bet on upgrading JDBC through Loom? Because if Loom keeps up with its promises, using JDBC in a coroutine style way seems *much* more compelling than relying on new SPIs and APIs. > "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. > That just shows that problems are solved on the wrong level, again. We need language / platform level support for asynchronicity. If everyone solves this on their own, what we get is a huge mess. > 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. > jOOQ will not worry about any such implementation specifics, because that's a can of worms I would not want to open (or maintain), see the epoll/nio/netty example. The good news is, R2DBC looks very promising and well designed. And it builds on top of a very good SPI: Reactive streams, which jOOQ 3.12 can depend on. So, if someone decides that a reactive streams based library like RxJava or Reactor is going to serve their needs, thanks to R2DBC, jOOQ can relatively easily bridge the client facing code (Reactor) with the database facing code (the R2DBC driver). Note that jOOQ just acts as a bridge, just like in the synchronous case of JDBC. It will not worry about connection pooling, threading, what not. This is why jOOQ didn't have a solution yet, because there was no R2DBC to rely upon. It would have been unwise to bind directly to individual, non-official third party drivers, such as e.g. the many little "reactive" PostgreSQL drivers. I hope this helps, Lukas -- 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/CAB4ELO7x0wmR_XU3bB5SCQEpyrkPt-o0Hg_K_qtsziS57D-n5w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
