Consider target transaction manager for traditional vs reactive transaction decision

[dittos]

In our app, we have several controller methods that construct Mono within JPA transaction and returns it.

Something like:

@PostMapping
@Transactional
fun handle(): Mono<Boolean> {
  val user = findUser()
  val subscription = user.subscriptions[0]
  return emailSender.send(subscription.email, ...)
}

Before 5.2, the transaction commits when the method returns, and the returned side effect gets executed without holding a transaction.

With reactive transactions introduced in 5.2, code like this breaks because JpaTransactionManager is not a ReactiveTransactionManager.

Currently there is no way to restore the previous behavior as reactive transaction handling is always active in TransactionAspectSupport. It would be easier to upgrade if there is a way to opt-out from reactive transaction behavior.

Some ideas:

• Globally disable reactive transactions: TransactionAspectSupport#setEnableReactiveTransactions(false)?
• Selectively disable reactive transactions: @Transactional(reactive = false)?

[dreis2211]

A colleague of mine noticed something similar when upgrading to Spring-Boot 2.2.

The project he is dealing with has some controller methods returning CompletableFutures (so technically not even classes of the reactor stack) and only includes spring-webflux to use WebClient functionalities. Unfortunately, the new behaviour prevents us from upgrading at the moment. A way to restore the previous behaviour would be therefore highly appreciated.

Cheers,
Christoph

[jhoeller]

I've revised our transaction manager determination algorithm to consider the target transaction manager, that is, it only goes into reactive transaction mode in case of a reactive return type plus a resolved ReactiveTransactionManager. This also allows for using qualifiers to select between traditional and reactive transaction managers now, determining the transaction mode that way.