java.sql2 DynamicMultiOperation with interlaced exceptions
lukas.eder at gmail.com
Sun Oct 15 14:48:43 UTC 2017
Without having written a POC yet, I'm positive it will be possible. jOOQ
currently binds to JDBC and runs blocking statements inside of a
CompletionStage abstraction on user-defined Executors. This makes jOOQ look
as though it were async-capable, even if it's just postponing the blocking
call, delegating it to some Executor that runs blocking JDBC.
I'm sure it will be possible to switch the internal "classic" JDBC usage by
the new API, keeping the user facing CompletionStage semantics.
I hope I'll have some time next week to implement an actual POC, and I'll
be more than happy to provide feedback.
2017-10-13 21:12 GMT+02:00 Douglas Surber <douglas.surber at oracle.com>:
> As I said in a previous thread, what would help me is if you explored
> whether it would be possible to implement the kind of API you are
> interested in using the proposed API?
> On Oct 13, 2017, at 11:56 AM, Lukas Eder <lukas.eder at gmail.com> wrote:
> 2017-10-13 17:55 GMT+02:00 Douglas Surber <douglas.surber at oracle.com>:
>> So shoehorning something into the reactive stream model just because you
>> can is against the explicit goals of the project. Per the quote above
>> “backpressure is an integral part of the model”. Using a reactive stream
>> where back pressure is of no value is bad design.
> OK, I tried :) but got it now. Thanks for your detailed responses.
More information about the jdbc-spec-discuss