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 toJdbcTemplate
but with methods returningMono<T>
(and maybeFlux<T>
like Spring Data does) instead ofT
and takingPublisher<T>
(n elements) orMono<T>
(1 element) parameters instead ofT
. - Provide an
ReactiveJdbcTempate
implementation that uses optionally customizableScheduler
s and execute various queries on these scheduler by callingpublishOn
orsubscribeOn
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)
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 aScheduler
that is based on the capacity of your machine, probably the number of CPUs.