3 ms·
What are you using for non-blocking database access? Is not JDBC a roadblock?
by songshu 7y ago
What are you using for non-blocking database access? Is not JDBC a roadblock?
- vbezhenar 7y agoYou 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.
- shock 7y agoWhy do you want db access to be non-blocking? Are you not interested in the result?
- erik_seaberg 7y agoI 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.
- shock 7y ago> 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).
- erik_seaberg 7y agoTrue, 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.
- jillesvangurp 7y agoI'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.