Tomasz NurkiewiczI struggle to find the benefits of #Spring #R2DBC. It's a full rewrite of #JDBC API using non-blocking I/O. However, typical application shouldn't open more than a handful of DB connections. So, just a few threads blocked on I/O (plus some threads queued up) shouldn't be an issue. Unless you want to be purely reactive or you are connecting to massively scalable database. But in that case, virtual threads come in handy. So what's the point? #Java #reactive
Nicolas Fränkel 🇺🇦🇬🇪@nurkiewicz You nailed it at “you want to be fully reactive”. How good would be a Reactive application that blocks at each database access?
wakingrufus@nurkiewicz
The r2dbc effort predates the availability of virtual threads and was designed with the fully reactive stack use case in mind, I believe. But since a service is likely to have more "threads" needing to access a database than total connections in the pool, the abstraction might still be useful to marshal the sharing of the connections in an event-loop style rather than 1:1 connection to virtual thread usage.
The r2dbc effort predates the availability of virtual threads and was designed with the fully reactive stack use case in mind, I believe. But since a service is likely to have more "threads" needing to access a database than total connections in the pool, the abstraction might still be useful to marshal the sharing of the connections in an event-loop style rather than 1:1 connection to virtual thread usage.
Oliver Drotbohm@nurkiewicz A few things (some of which you’re likely aware of):
1. R2DBC was coined in the context of apps being candidates for a reactive stack but needed to talk to an R2DBMS.
2. How do you get backpressure propagated into the database with JDBC? Slow reader attacks still kill your app.
3. What if those hand full of connections are running long-lasting queries and are easily saturated?
4. R2DBC was running in production systems before anyone even remotely spoke of Loom publicly.
1. R2DBC was coined in the context of apps being candidates for a reactive stack but needed to talk to an R2DBMS.
2. How do you get backpressure propagated into the database with JDBC? Slow reader attacks still kill your app.
3. What if those hand full of connections are running long-lasting queries and are easily saturated?
4. R2DBC was running in production systems before anyone even remotely spoke of Loom publicly.