3

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?

Oiew
  • 1,509
  • 1
  • 11
  • 14

1 Answers1

8

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.

Martin Tarjányi
  • 8,863
  • 2
  • 31
  • 49
  • I like to add that combining Webflux with JDBC could lead to deadlocks when all Scheduler threads are blocked by JDBC but the subscriber still pulls new elements. (I learned that painfully in an application that is already in production) – Stephan Dec 20 '19 at 09:51
  • actually, jdbc is production ready, it's not the case for r2dbc, maybe in 6 month – robert trudel Dec 29 '19 at 15:47
  • Based on what criteria will you consider r2dbc production-ready? It had a GA release a month ago. – Martin Tarjányi Dec 29 '19 at 15:55