Document behaviour of @Transactional in reactive environments with non-reactive signatures

[michael-simons]

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.

[michael-simons]

Adding this in a good way would also explain easy and fast why @Transactional on a @Test is always imperative.

[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.