Better DependsOn relationships

[mauromol]

Describe the bug
The Spring Boot integration is setting up:

• a UserTransactionService
• a UserTransactionManager
• an AtomikosDependsOnBeanFactoryPostProcessor that is making the UserTransactionManager depend on any DataSource and ConnectionFactory

However, if I understand Atomikos correctly:

• the UserTransactionService should be start before the UserTransactionManager, so that the latter can retrieve the configuration set up by the former; for this reason, I'd expect a @DependsOn("userTransactionService") on atomikosTransactionManager
• the UserTransactionService itself needs the data sources (and I guess the connection factories) to be available, at least on shutdown; for this reason I would expect that AtomikosDependsOnBeanFactoryPostProcessor applies the same logic on the UserTransactionService (or, better, only on that, once the UserTransactionManager had itself the "depends on" relationship of the previous point, causing it to transitively depend on the data sources/connection factories itself)

Indeed, once I started to implement Atomikos on my project, I goot XA errors on the UserTransactionService shutdown, because a last recovery pass is made during shutdown and one of the two data sources were already shut down before the service (Oracle was indeed returning error ORA-17008). Problem solved by adding manually such "depends on" relationships.
Unfortunately AtomikosDependsOnBeanFactoryPostProcessor cannot be easily extended, since its methods are private.

To Reproduce
Using Transaction Essentials 6.0.0 on Spring Boot 4.
Needed to re-write the configuration myself, by mimicking the AtomikosAutoConfiguration, due to it being incompatible with Spring Boot 4. I also needed more flexibility to set up my multiple data sources.

I'll try to add a screenshot separately, upload is failing right now.

Additional context
Setting up Atomikos transaction manager with Spring JTA XA transaction manager, in Spring Boot 4, using two distinct data sources.

I understand that this project is not intended for support - because bug reports may or may not be considered for inclusion some day (in a future release). If this is issue is important to me then I can go to https://www.atomikos.com/Main/SupportOverview and arrange a paid support subscription.

[pascalleclercq]

Hi @mauromol thank you for your feedback !
We took AtomikosDependsOnBeanFactoryPostProcessor from Spring Boot repository when SB team dropped the Atomikos support.
Obviously the DependsOn relationship between UserTransactionManager and UserTransactionServiceImp is missing.
Here is a suggested change:

Can you tell us what you think about It ? Do you have an idea on how to check if It's Ok ?

[mauromol]

Looks good to me (maybe I would just rename "addTransactionManagerDependencies" to "addTransactionServiceDependencies").
Please note that the dependency between the manager and the service could also just simply be put on the transaction manager bean declaration directly, probably no real need to scan for all transaction managers in this case:

  @Bean(initMethod = "init", destroyMethod = "close")
  @DependsOn("userTransactionService")
  UserTransactionManager atomikosTransactionManager() {
    final UserTransactionManager manager = new UserTransactionManager();
    manager.setStartupTransactionService(false);
    manager.setForceShutdown(true);
    return manager;
  }

Regarding how to test: probably not trivial. However, I was wondering if this problem never happened to you, at least when having multiple data sources (two in my case). Unfortunately, I can't upload images here (GitHub says "failed upload", I don't know if there's some block in your issue tracker), but in my case the stack trace where I was getting issues (i.e.: data source already closed when the transaction service was being shut down by Spring) is the following:

SQLRecoverableException - ORA-17008: Closed connection - used to create a XAException

• OracleXADataSource.recover:77
• RecoveryScan.recoverXids:32
• XARecoveryManager.retrievePreparedXidsFromXaResource:265
• XARecoveryManager.recover:93
• XATransactionalResource.recover:375
• RecoveryDomainService.performRecovery:82
• TransactionServiceImp.performRecoveryPass:674
• TransactionServiceImp.shutdown:561
• Configuration.shutdown:325
• UserTransactionServiceImp.shutdown:85
• UserTransactionServiceImp.shutdownWait:158

From the second line on, it's Atomikos Transaction Essentials 6.0 source code.
Maybe with this you can get an idea on how to write a proper test.

I solved this problem by setting the above "depends on" declaration: in this way, data sources are closed after the UserTransactionServiceImp has been shut down.

[pascalleclercq]

Adding the @DependsOn annotation is a very good idea but I think this should do the same trick as we have in the code base:

    @Bean(initMethod = "init", destroyMethod = "close")
    @ConditionalOnMissingBean(TransactionManager.class)
    UserTransactionManager atomikosTransactionManager(UserTransactionService userTransactionService) throws Exception {
        UserTransactionManager manager = new UserTransactionManager();
        manager.setStartupTransactionService(false);
        manager.setForceShutdown(true);
        return manager;
    }

as you can see the userTransactionService is injected as a parameter during the creation of the atomikosTransactionManager Bean. This must garantee the userTransactionService is created and initialized before atomikosTransactionManager, isn't It ?

[mauromol]

I'm not 100% sure this will work in case of lazy initialization, since the UserTransactionManager is not querying the service: will Spring ensure that the latter initialization is anyway performed before the former's one in this case? IMHO using "depends on" is safer. And it would be more "explicit" on what is going on here (that is, the manager needs the service to be up even if it apparently does not query it during construction).