Application Does Not Start When Multiple `TransactionManager` Bean Exist

[NYPD]

Expected Behavior

Spring Session with JDBC supports declaring a datasource with the use of the @SpringSessionDataSource annotation to tell Spring Session which datasource to use. However, if an application has multiple transaction managers, there is no way to tell Spring Session which one to pick directly and has to be done with declaring the bean as "Primary". It would be nice if there was a @SpringSessionTransactionManager to use instead.

Current Behavior

With applications that have multiple transaction managers setting one of them as "primary" is needed even if one does not wish to set it primary.

@Bean
public PlatformTransactionManager transactionManager1(DataSource mainAppDatasource) {
    return new DataSourceTransactionManager(mainAppDatasource); 
}

@Bean
@Primary
public PlatformTransactionManager transactionManager2(DataSource springSessionDatasource) {
     return new DataSourceTransactionManager(springSessionDatasource); 
}

Context

I have inherited a application that contains 4 JDBC datasources, each with their own transaction managers. Incorporating Spring Session can only be done with making one of them primary.

[NYPD]

Looking into the JdbcHttpSessionConfiguration.java class I noticed this:

@Autowired
public void setTransactionManager(PlatformTransactionManager transactionManager) {
    this.transactionManager = transactionManager;
}

@Autowired(required = false)
@Qualifier("springSessionTransactionOperations")
public void setTransactionOperations(TransactionOperations transactionOperations) {
    this.transactionOperations = transactionOperations;
}

Providing a dedicated TransactionOperations would also work and naming the bean "springSessionTransactionOperations", but it will still run into the "multiple transaction managers found" issue with the setTransactionManager() method.

Maybe making the setTransactionManager method to be @Autowired(required = false) and perhaps adding a @Qualifier could simplify things. Of course it will have to throw an exception on the JdbcIndexedSessionRepository bean creation if neither are present.

[marcusdacoregio]

Hi, @NYPD. Thanks for the report.

but it will still run into the "multiple transaction managers found" issue with the setTransactionManager() method.

Did you expose two beans of type TransactionManager, one qualified with springSessionTransactionOperations? If so you would have to mark one of them as @Primary to avoid the error above. I think that another way is to expose one bean of type TransactionTemplate and another of type TransactionOperations for Spring Session, which is the type that the setter method expects:

@Bean
TransactionManager myTransactionManager() {
    return new MyTransactionManager();
}

@Bean("springSessionTransactionOperations")
TransactionOperations springSessionTransactionOperations() {
    return new MyTransactionOperations();
}

[NYPD]

Hey @marcusdacoregio, I did expose multiple beans with type transactionManager which is where i ran into the issue.

The code you provided will work, and would be perfect for an application with just two datasources, one datasource to a specific JDBC connection and another to the spring session datasource. However, in an application with 3 or more datasources, each with their own transactionManager, then it lead to some issues.

Take this psuedo code for example:

@Bean("datasource1")
public Datasource datasourceToDatabase1() {
    return new datasource();
}
 
@Bean
public Platformtransactionmanager transactionManager1(@qualifier("datasource1") Datasource datasource) {
    return new DataSourceTransactionManager(datasource); 
}
 
@Bean("datasource2")
public Datasource datasourceToDatabase2() {
    return new Datasource ();
}
 
@Bean
public Platformtransactionmanager transactionmanager2(@qualifier("datasource2") Datasource datasource) {
    return new DataSourceTransactionManager(datasource); 
}
 
@Bean
@SpringSessionDataSource 
public Datasource springSessionDatasource() {
    return new Datasource ();
}
 
@Bean("springSessionTransactionOperations")
public TransactionOperations springSessionTransactionOperations() {
    return new MyTransactionOperations();
}
 

When trying to run this it will print out:

***************************
application failed to start
***************************
 
Description:
 
parameter 0 of method setTransactionManager in org.springframework.session.jdbc.config.annotation.web.http.jdbchttpsessionconfiguration required a single bean, but 2 were found:
                - transactionmanager1: defined in unknown location
                - transactionmanager2: defined in unknown location
 
this may be due to missing parameter name information
 
action:
 
consider marking one of the beans as @primary, updating the consumer to accept multiple beans, or using @qualifier to identify the bean that should be consumed
 

This is because in the JdbcHttpSessionConfiguration.java class as you know has:

@Autowired
public void setTransactionManager(PlatformTransactionManager transactionManager) {
    this.transactionManager= transactionManager;
}

and it does not know which PlatformTransactionManager to use. In the JdbcIndexedSessionRepository bean method creation of the JdbcHttpSessionConfiguration.java at line 117 we see this:

@Bean
public JdbcIndexedSessionRepository sessionRepository() {
    JdbcTemplate jdbcTemplate = createJdbcTemplate(this.dataSource);
    if (this.transactionOperations == null) {
	this.transactionOperations = createTransactionTemplate(this.transactionManager);
    }
}

Where if the application did not provide a transactionOperations bean, the constructor creates one from the Platformtransactionmanager it found, which is a bit weird since this.transactionManager is never used anywhere in the class besides the bean creation method where it is used to create a transactionOperations. Meaning the this.transactionManager is optional even though it is forced to be present on start up

What I'm proposing is for JdbcHttpSessionConfiguration.java to be changed to something like so:

@Autowired(required = false)
@SpringSessionTransactionManager
public void setTransactionManager(Platformtransactionmanager transactionManager) {
    this.transactionManager= transactionManager;
}
 
@Autowired(required = false)
@Qualifier("springsessiontransactionoperations")
public void setTransactionOperations(TransactionOperations transactionOperations) {
    this.transactionOperations= transactionOperations;
}

and then during bean creation a check can be made to see if either or bean was found in the context and if not perhaps throw a new runtime exception (throw new runtimeException("no Platformtransactionmanager or TransactionOperations provided");) or something like that.

As you and i mentioned, the only way around this scenario is to mark a transaction manager with @primary, but i think it would be better to not force the developer to do this because maybe the @Bean("datasource1") is the the actual primary datasource of the application.

I could create a pull request, but I'm not too familiar with the testing side nor spring coding practices. I might need some help/guidance for those.

Please excuse the camel and capital case issues in all the example code, i tried to fix it, but something weird happened copying my response from vscode to here.

[marcusdacoregio]

Hi, @NYPD. That makes sense, even when providing a TransactionOperations with the proper qualifier the application still fails to startup if there are multiple TransactionManagers. To avoid breaking passivity, we can change the setter to not required and also qualify it with a bean name:

@Autowired(required = false)
@SpringSessionTransactionManager
public void setTransactionManager(PlatformTransactionManager transactionManager) {
	this.transactionManager = transactionManager;
}

And then, after the bean is initialized, we can verify if this.transactionManager == null and try to resolve a unique bean from the application context, something like:

@Override
public void afterPropertiesSet() throws Exception {
	if (this.transactionOperations == null && this.transactionManager == null) {
		this.transactionManager = getUniqueTransactionManager();
		if (this.transactionManager == null) {
			throw new IllegalStateException(
					"""
							Could not resolve an unique PlatformTransactionManager bean from the application context.
							Please provide either a TransactionOperations bean or a PlatformTransactionManager qualified with @SpringSessionTransactionManager""");
		}
	}
}

I'll be working on that fix for the next patch releases.