Given a scenario with a ReactiveTransactionManager
in the context, I expected methods annotated with @Transactional
handled by this transaction manager.
However, only methods exposing some sort of reactive API (Flux
, Mono
and related) are handled via TransactionAspectSupport
.
So given a component like
static class Foobar {
@Transactional
public void boom() {
}
@Transactional
public Mono<Void> imFine() {
return Mono.empty();
}
}
would effectively need two transaction managers, or at one of the methods will fail. With only a reactive transaction manager, boom
fails:
java.lang.IllegalStateException: Specified transaction manager is not a PlatformTransactionManager:
While boom
is probably not a method that can be used in a sensible way in a reactive context, it's something that's gonna happen eventually and should be at least documented.
As I don't have a good idea, what else to use to decide about which transaction manager to use, I try not to suggest making it work in another way, but just be very clear in the docs about what to expect.
Comment From: michael-simons
Adding this in a good way would also explain easy and fast why @Transactional
on a @Test
is always imperative.
Comment From: jhoeller
The exception is already different and more expressive now than above: "Cannot apply reactive transaction to non-reactive return type [void] with specified transaction manager: ..." - I'll also add corresponding documentation notes for @Transactional
.