You run threadpool of JDBC workers and pretend like it's non-blocking now.

Though there are some experimental non-JDBC drivers using non-blocking I/O to move your blocking code from backend into database. In the end you're still blocking.

Why do you want db access to be non-blocking? Are you not interested in the result?

I want to resume business logic when the result is available, but I don't want tens of thousands of kernel threads blocked on results until java finally gets fibers. People who write synchronous drivers also tend to make big poorly-used connection pools which defeat TCP flow control.

> I don't want tens of thousands of kernel threads blocked on results

If that is because of the memory consumption of kernel threads, be aware you are trading less memory consumption for increased cognitive complexity (if you agree that asynchronicity is more complex than synchronicity).

True, if hardware cost nothing we might still be on python. Chaining futures with f1.thenApply(arg -> f2) hasn't been that bad, but kotlin's coroutine DSL does look better.

I've not yet done any non blocking DB stuff. JDBC is blocking but there's R2DBC in the spring world that you can use. There are probably a few other options.