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.