Janning Vygen opened SPR-6661 and commented

Using Multiple Transaction Managers with @Transactional works like a charme if you only have one BeanFactory. doc reference is here: http://static.springsource.org/spring/docs/3.0.x/reference/html/transaction.html#tx-multiple-tx-mgrs-with-attransactional

but i have a projects which depends on another spring project which is integrated by starting a second beanFactory. Each BeanFactory has its own TransactionManager (and its own SessionFactory and DataSource). Even if i annotate all @Transactional Annotations with a qualifier like described in the docs, it does not work.

This is because TransactionAspectSupport.determineTransactionManager(TransactionAttribute txAttr) relies on a beanFactory reference for resolving a matching transactionManager. But transactionAspectSupport is a singleton aspect. So we have two beanFactories but only one instance of TransactionAspectSupport. So when i load my second beanFactory TransactionAspectSupport.setBeanFactory is called again and the initial beanFactory reference is lost.

this could be prevented if TransactionAspectSupport has a set of beanFactories and iterating over them when searching for a matching qualifier.

BTW, i think there is an documentation bug: http://static.springsource.org/spring/docs/3.0.x/reference/html/transaction.html#transaction-declarative-annotations it says: " only looks for @Transactional on beans in the same application context it is defined in." This is not true for mode="aspectj", isn't it?

Affects: 3.0 GA

5 votes, 7 watchers

Comment From: spring-projects-issues

Gabriel Guernik commented

This is issue can also appear if you are using Spring's context caching support in your JUnit tests. If the test classes use different contexts, the TransactionAspectSupport will hold references to the beans of a wrong context.

Comment From: spring-projects-issues

Bulgar Sadykov commented

More precisely TransactionAspectSupport will hold a reference to first application context used (e.g. if you have two instances of application context based on the same configuration).

Comment From: spring-projects-issues

Ian Dallas commented

What is the status on this? With the @ActiveProfiles annotation added in 3.1 this exacerbates this issue. If you have a series of tests that use different Spring profiles then a new application context is created for each set of active profiles. Switching from a test with AppContextA to one with AppContextB then back to a test with AppContextA will immediately show the problem if there are any places were lazy loading of collections is involved.

It is my opinion that this is a higer priority issue than "minor".

Comment From: spring-projects-issues

Juergen Hoeller commented

The reason why this hasn't been seen as higher priority is that it primarily affects testing scenarios, and only when using mode="aspectj" there. For actual application deployment, TransactionAspectSupport isn't meant to deal with more than one BeanFactory at this point; opening it up to multi-context scenarios is a major refactoring.

That said, point taken, we should revisit what we can do here. I'm scheduling that effort for the 4.1 timeframe.

Juergen

Comment From: spring-projects-issues

Ian Dallas commented

Excellent! Thank you very much for the update. I look forward to seeing the resolution.

Comment From: spring-projects-issues

Ian Dallas commented

Is there any new status on this defect?

Comment From: spring-projects-issues

Ian Dallas commented

No status updates yet? This was planned to be fixed 6 months ago and ended up getting moved from the 4.1 release.

Comment From: jhoeller

This is effectively superseded by #11019 (also in the backlog with low priority).