Speaking of R2DBC, I was reading that making JDBC ...
# spring
l
Speaking of R2DBC, I was reading that making JDBC non blocking has insignificant benefits because the databases can only do so much at any given time, so if you have say a pool of 30 threads to do database calls, that is already more operations than the database can do concurrently anyway so making it non blocking will simply save you the overhead of the thread pool. So what is the big deal about nonblocking JDBC ? Anyone disagree?
f
IMO it's mostly about the convenience of being able to write async-looking code that fits with whatever async-based framework you're using (Vertx, Ktor, etc). You can always use async code synchronously, but can't fake async-ness with something that is synchronous.
👍 1
d
I did have a case where my dataset was too big too fit it on memory using Spring JDBC, but with R2DBC I was able to process it using Flux