Skip to content

Modify @ConditionalOnMissingBean of transactionManager in JdbcTransactionManagerConfiguration #35261

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
wants to merge 5 commits into from

Conversation

davin111
Copy link
Contributor

@davin111 davin111 commented May 4, 2023

In JdbcTransactionManagerConfiguration, the transactionManager bean is registered if there is no bean of TransactionManager types. However, the autoconfiguration is responsible for jdbc transactionmanagers related with PlatformTransactionManager, not ReactiveTransactionManager. For now, with an existing ReactiveTransactionManager, this autoconfiguration doesn't register the expectable transactionmanager. I think the condition of the transactionManager() bean method should be modified.

I added a test related with it, and fixed one existing test because it didn't configure DataSourceAutoConfiguration, which made the test vacuously true.


After I made this PR, I checked the issue #22851 which is opposite. It said like below.

Considering that framework expects a single bean of that type for unqualified @Transactional use, I think we should refine our auto-configuration to avoid that by default.

I also agreed with it, but I made this PR because when I develop a spring batch application with jdbc for JobRepository and r2dbc for main service and repository logic, I figured out this condition of the autoconfiguration prevents registering the required jdbc transactionmanager. Please give your opinion about this and I can close this PR or modify PR only for fixing the existing test.

@pivotal-cla
Copy link

@davin111 Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

@pivotal-cla
Copy link

@davin111 Thank you for signing the Contributor License Agreement!

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label May 4, 2023
@snicoll
Copy link
Member

snicoll commented May 4, 2023

I can confirm that the transaction auto-configuration is doing this on purpose and having more than one transaction managers is not something we'd expect. You shouldn't mix jdbc and R2DBC in the same app for a similar reason.

@snicoll snicoll closed this May 4, 2023
@snicoll snicoll added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-triage An issue we've not yet triaged labels May 4, 2023
@davin111
Copy link
Contributor Author

davin111 commented May 5, 2023

@snicoll Do you think having more than one transaction managers should be avoided, even though @Transactional supports the way to specify which transactionManager should be used? I think some apps can have both transactionManagers for some special purposes.

@snicoll
Copy link
Member

snicoll commented May 5, 2023

Yes, and you are right that some apps can have multiple transaction managers. These are meant for multi-ressources transaction management, such as a JMS resource and a JDBC resource. Our auto-configuration should promote the standard way of doing things, which is why this PR was declined.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants