Repository navigation
Help users to avoid mismatched DataSource and TransactionManager pairs #5388
Description
Expected Behavior
When using its JDBC support, Batch should do what it can to protect against someone misconfiguring the DataSource and TransactionManager. If Batch can identify that its DataSource is not the same as its TransactionManager's DataSource, it should log a warning or even fail fast when starting up.
Current Behavior
The misconfiguration is ignored.
Context
I'd like an arrangement like this to fail or at least log a warning:
@EnableBatchProcessing
@EnableJdbcJobRepository(dataSourceRef = "firstDataSource")
public class BrokenTransactionConfigurationApplication {
private final DataSource firstDataSource = new EmbeddedDatabaseBuilder().build();
private final DataSource secondDataSource = new EmbeddedDatabaseBuilder().build();
@Bean
DataSource firstDataSource() {
return new EmbeddedDatabaseBuilder().build();
}
@Bean
DataSource secondDataSource() {
return new EmbeddedDatabaseBuilder().build();
}
@Bean
DataSourceTransactionManager firstTransactionManager() {
return new DataSourceTransactionManager(this.firstDataSource);
}
@Bean
DataSourceTransactionManager transactionManager() {
return new DataSourceTransactionManager(this.secondDataSource);
}
public static void main(String[] args) {
SpringApplication.run(BrokenTransactionConfigurationApplication.class, args);
}
}You could also get into a similar state by sub-classing JdbcDefaultBatchConfiguration and overriding getDataSource() and/or getTransactionManager(). For Spring Boot users, @BatchDataSource and @BatchTransactionManager are another way.
I think all these approaches end up configuring a JdbcJobRepositoryFactoryBean. Hopefully that provides a central place where some validation of the configured DataSource and TransactionManager could be done to catch misconfigurations early and irrespective of how they arose.
Activity
quaff commentedon May 6, 2026
What if provided
TransactionManageris notDataSourceTransactionManager?wilkinsona commentedon May 6, 2026
That's no different to any other combination. The goal would be for Batch, on a best-effort basis, to determine whether or not the combination is valid and to inform the user if it is not.
quaff commentedon Jun 5, 2026
FYI, Spring AI will create DataSourceTransactionManager for JdbcChatMemoryRepository if no explicit one present.
https://github.com/spring-projects/spring-ai/blob/ba1518bf79925867fc6ab807f98e43403d81fdf9/memory/repository/spring-ai-model-chat-memory-repository-jdbc/src/main/java/org/springframework/ai/chat/memory/repository/jdbc/JdbcChatMemoryRepository.java#L75-L86
DragonFSKY commentedon Jun 22, 2026
I can take a look at this. I’ll keep the scope focused on a best-effort, warning-only check in
JdbcJobRepositoryFactoryBeanthat compares the configured JobRepositoryDataSourcewith aDataSourceresource factory exposed by aResourceTransactionManager, with focused tests for the supported and skipped cases.spring-projectsGH-5388: Warn about mismatched JobRepository DataSource
DragonFSKY commentedon Jun 22, 2026
I opened PR #5437 with a focused, warning-only implementation.
The check is intentionally best-effort: it runs in
JdbcJobRepositoryFactoryBean, compares the configured JobRepositoryDataSourcewith aDataSourceresource factory exposed by aResourceTransactionManager, and skips cases where the resource cannot be determined as aDataSource.spring-projectsGH-5388: Warn about mismatched JobRepository DataSource
spring-projectsGH-5388: Warn about mismatched JobRepository DataSource
spring-projectsGH-5388: Isolate the mismatch check and keep the inher…
spring-projectsGH-5388: Resolve the repository DataSource inside the …
spring-projectsGH-5388: Resolve the transaction manager inside the di…