CODEWITHSUNDEEP
spring-webfluxr2dbcspring-data-r2dbc
Oiew
Oiew

Reputation: 1529

What is the motivation for using R2DBC?

I am very new to reactive spring stack and currently exploring R2DBC.

Could you explain me what are the benefits of using R2dbcRepository over wrapping blocking JpaRepository into Mono/Flux?

Let me bring some example of that:

val producer: Mono<BookEntity> = booksReactiveRepository.findById(id)

vs

val producer: Mono<BookEntity> = Mono.fromSupplier { booksBlockingRepository.findById(id) }

Is there any conceptual difference on execution?

Upvotes: 3

Views: 2170

Answers (1)

Martin Tarj&#225;nyi
Martin Tarj&#225;nyi

Reputation: 9987

The main difference is that JDBC/JPA uses blocking I/O which means each request needs a dedicated thread. In highly concurrent systems this can easily lead to scaling problems.

On the other hand R2DBC uses non-blocking I/O, which means it is able to handle requests with only a fixed, low number of threads, which makes scaling easier and cheaper.

Check the following article: https://spring.io/blog/2018/12/07/reactive-programming-and-relational-databases

Java uses JDBC as the primary technology to integrate with relational databases. JDBC is of a blocking nature – there’s nothing sensible one could do to mitigate the blocking nature of JDBC. The first idea for how to make calls non-blocking is offloading JDBC calls to an Executor (typically Thread pool). While this approach somewhat works, it comes with several drawbacks that neglect the benefits of a reactive programming model.

Thread pools require – no surprise – threads to run. Reactive runtimes typically use a limited number of threads that match the number of CPU cores. Additional threads introduce overhead and reduce the effect of thread limiting. Additionally, JDBC calls typically pile up in a queue, and once the threads are saturated with requests, the pool will block again. So, JDBC is right now not an option.

Upvotes: 9

Related Questions