Skip to content

TransactionAspectSupport fails to select reactive transaction manager when both transaction manager variants are present #25532

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
michael-simons opened this issue Aug 5, 2020 · 2 comments
Assignees
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) type: enhancement A general enhancement

Comments

@michael-simons
Copy link
Contributor

michael-simons commented Aug 5, 2020

Given a transactional, reactive service:

@Service
static public class S {
	@Transactional
	public Flux<String> something() {
		return Flux.just("foobar");
	}
}

and two transaction managers in the context, one being an instance of AbstractPlatformTransactionManager and one AbstractReactiveTransactionManager, the service should use the reactive transaction manager as indicated by the return type.

However, the TransactionAspectSupport fails to determine the correct one to use.

In determineTransactionManager it ultimately asks the beanFactory for an instance of TransactionManager, which fails with a org.springframework.beans.factory.NoUniqueBeanDefinitionException.

A workaround would be specifying which tx manager to use on the annotation or to provide a configured like this

@Component
static class F implements TransactionManagementConfigurer {

	private final ReactiveTransactionManager reactiveTransactionManager;

	public F(ReactiveTransactionManager reactiveTransactionManager) {
		this.reactiveTransactionManager = reactiveTransactionManager;
	}

	@Override
	public TransactionManager annotationDrivenTransactionManager() {
		return reactiveTransactionManager;
	}
}

but that would be contra intuitive compared to how this is solved with Spring Data repositories.

Having two very distinguishable transaction managers on the context will be the case with the upcoming changes in Spring Boot 2.4 and Spring Data Neo4j 6: It will bring an imperative and a reactive one, thus leading to problems described here.

@mp911de and I hope for respectively suggest a change in the TransactionAspectSupport so that it tries to determine the need for a reactive transaction manager before actually determining one and use the information - if available - to narrow down the selection of the transaction manager in cases where none is configured otherwise.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Aug 5, 2020
@jhoeller jhoeller self-assigned this Aug 5, 2020
@jhoeller jhoeller added in: data Issues in data modules (jdbc, orm, oxm, tx) type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Aug 5, 2020
@jhoeller jhoeller added this to the 5.3 M2 milestone Aug 5, 2020
@jhoeller jhoeller changed the title TransactionAspectSupport fails to select reactive transaction manager when 2 transaction managers are present. TransactionAspectSupport fails to select reactive transaction manager when both transaction managers variants are present Aug 6, 2020
@jhoeller jhoeller removed this from the 5.3 M2 milestone Aug 10, 2020
@sbrannen sbrannen changed the title TransactionAspectSupport fails to select reactive transaction manager when both transaction managers variants are present TransactionAspectSupport fails to select reactive transaction manager when both transaction manager variants are present Aug 10, 2020
@jhoeller
Copy link
Contributor

Let's discuss the target scenarios in Boot before we add any extra selection steps in the core transaction support: see spring-projects/spring-boot#22851 - let's see what we can or need to do for 5.3 RC1 then.

@snicoll
Copy link
Member

snicoll commented Aug 25, 2020

We've decided to stop auto-configuring the Neo4j reactive transaction manager and Spring Boot now looks for the presence of a TransactionManager rather than just a PlatformTransactionManager (or ReactiveTransactionManager). We believe that rather configuring both, Spring Boot should offer a more fine grained way to declare the user intention. This discussion is happening in spring-projects/spring-boot#22692 - I don't have an opinion as whether the core framework should support both transaction managers though but that doesn't seem something we'd like to do out-of-the-box at least.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

4 participants