ReactiveJdbcTemplate

ReactiveJdbcTemplate.md

Since there seems to be some interest abbout the possibility to run WebFlux + SQL applications, I think there is maybe a room for a community driven project to experiment around this topic. Some guidelines or ideas I can share on that topic:

• Learn from https://github.com/davidmoten/rxjava-jdbc#asynchronous-queries and http://vertx.io/docs/vertx-jdbc-client/java/
• Have a look to https://github.com/spring-projects/spring-data-commons/blob/master/src/main/java/org/springframework/data/repository/reactive/ReactiveCrudRepository.java versus https://github.com/spring-projects/spring-data-commons/blob/master/src/main/java/org/springframework/data/repository/CrudRepository.java to have an example of a Reactive API compared to a blocking one applied to persistence
• Create a ReactiveJdbcTempate interface that provides an API similar to JdbcTemplate but with methods returning Mono<T> (and maybe Flux<T> like Spring Data does) instead of T and taking Publisher<T> (n elements) or Mono<T> (1 element) parameters instead of T.
• Provide an ReactiveJdbcTempate implementation that uses optionally customizable Schedulers and execute various queries on these scheduler by calling publishOn or subscribeOn on the right place see http://projectreactor.io/docs/core/release/reference/#schedulers and https://github.com/reactor/lite-rx-api-hands-on/blob/complete/src/main/java/io/pivotal/literx/Part11BlockingToReactive.java
• There could be 2 schedulers used:
  • One backed by a ThreadPool with the same size as the connection pool, a queue and a configurable timeout with proper backpressure for DB interactions
  • A second one to publish the results (based on the capacity of your machine, probably the number of CPUs)
• See if we can take advantage of Reactor 3.1 Context to replace thread local for transactions http://projectreactor.io/docs/core/release/reference/#context
• This can be done in Java or Kotlin (nothing Kotlin specific I think)

but with methods returning Mono
should be
but with methods returning Mono or Flux

I thought a little about the Scheduler. I think it might be better to support two schedulers: one as described which is used for executing queries and a second one (which might be the default scheduler of the application if something like this exists) to publish the results.

The idea would be that the DB interaction happens on a Scheduler that is essentially based on the connection pool, but you subscribe to the results on a Scheduler that is based on the capacity of your machine, probably the number of CPUs.

Yeah good points, I update the doc!