The Lovelace Release introduced early support for reactive transactions in a closure-fashioned style that left some room for improvements. The following listing shows that style:
Reactive Transactions in Lovelace (with MongoDB)
public Mono<Process> doSomething(Long id) {
return template.inTransaction().execute(txTemplate -> {
return txTemplate.findById(id)
.flatMap(it -> start(txTemplate, it))
.flatMap(it -> verify(it))
.flatMap(it -> finish(txTemplate, it));
}).next();
}
In the preceding snippet, the transaction has to be initiated by explicitly calling inTransaction() with a transaction-aware template within the closure, calling next() at the end to turn the returned Flux into a Mono to satisfy the method signature, even though findById(…) already emits only a single element.
Obviously, this is not the most intuitive way of doing reactive transactions. So let’s have a look at the same flow using declarative reactive transaction support. As with Spring’s transaction support, you need a component to handle the transaction for you. For reactive transactions, a ReactiveTransactionManager is currently provided by the MongoDB and R2DBC modules. The following listing shows such a component:
@EnableTransactionManagement
class Config extends AbstractReactiveMongoConfiguration {
// …
@Bean
ReactiveTransactionManager mgr(ReactiveMongoDatabaseFactory f) {
return new ReactiveMongoTransactionManager(f);
}
}
From there, you can annotate methods with @Transactional and rely on the infrastructure to start, commit, and roll back transactional flows to handle the lifecycle via the Reactor Context. This lets you turn the code from Lovelace into the following listing, removing the need for the closure with its scoped template and the superfluous Flux to Mono transformation:
Declarative Reactive Transactions in Moore (with MongoDB)
@Transactional
public Mono<Process> doSomething(Long id) {
return template.findById(id)
.flatMap(it -> start(template, it))
.flatMap(it -> verify(it))
.flatMap(it -> finish(template, it));
}
