Skip to content

Elaborate usage of PlatformTransactionManager #4787

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

Open
quaff opened this issue Mar 19, 2025 · 1 comment
Open

Elaborate usage of PlatformTransactionManager #4787

quaff opened this issue Mar 19, 2025 · 1 comment
Labels
for: backport-to-5.2.x Issues that will be back-ported to the 5.2.x line in: documentation type: enhancement
Milestone

Comments

@quaff
Copy link
Contributor

quaff commented Mar 19, 2025

There are many places to configure transactionManager, it's unclear whether it's mandatory or not, from my understanding, it's should be optional since dataSource is mandatory, Spring Batch could create DataSourceTransactionManager() as default, correct me if I'm wrong.

And it's unclear whether it's used for batch metadata operations or JDBC reader/writer of step, if Spring Boot's @BatchDataSource and @BatchTransactionManager are used for separated DataSource, which transactionManager should be used for StepBuilder::chunk?

public <I, O> SimpleStepBuilder<I, O> chunk(int chunkSize, PlatformTransactionManager transactionManager) {

@quaff quaff added the status: waiting-for-triage Issues that we did not analyse yet label Mar 19, 2025
@fmbenhassine
Copy link
Contributor

Spring Batch could create DataSourceTransactionManager() as default, correct me if I'm wrong.

Spring Batch used to do that, but it was causing issues like #816.

it's unclear whether it's used for batch metadata operations or JDBC reader/writer of step

Those can be different: one can use a ResourcelessTransactionManager for meta-data and a JdbcTransactionManager for business data.

I will plan to clarify the docs with a note about this.

@fmbenhassine fmbenhassine added in: documentation type: enhancement for: backport-to-5.2.x Issues that will be back-ported to the 5.2.x line and removed status: waiting-for-triage Issues that we did not analyse yet labels May 22, 2025
@fmbenhassine fmbenhassine added this to the 6.0.0 milestone May 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: backport-to-5.2.x Issues that will be back-ported to the 5.2.x line in: documentation type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants