Skip to content

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

@michael-simons

Description

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

Metadata

Metadata

Assignees

Labels

in: dataIssues in data modules (jdbc, orm, oxm, tx)type: documentationA documentation task

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions