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
@Transactional qualifier is ignored by TransactionAspectSupport if default transaction manager is set [SPR-12541] #17145
Comments
Sam Brannen commented This issue is related to #17123. |
Stéphane Nicoll commented I don't see the link Sam. It's liked to #16570 but I don't see the relationship with #17123: the problem here is about the qualifier not being applied anymore, not a side-effect of caching. |
Sam Brannen commented The code block that Donnchadh questions on GitHub hasn't changed recently. if (this.transactionManager != null || this.beanFactory == null || txAttr == null) {
return this.transactionManager;
} What has changed is that the default transaction manager is now cached in an instance variable within the aspect: else {
// Lookup the default transaction manager and store it for next call
this.transactionManager = this.beanFactory.getBean(PlatformTransactionManager.class);
return this.transactionManager;
} The fact that I haven't investigated it fully, but it appears that the issue Donnchadh has reported would actually have been present with JavaConfig prior to Spring 4.1 if the developer implemented In summary, I don't believe that this is entirely a new issue. It's just that setting the In addition, I think we should change all of the documentation involving this particular Does that make sense? Cheers, Sam |
Sam Brannen commented With regard to the term caching, I consider both the I hope that clears up any confusion I may have caused with the word "caching". ;) |
Sam Brannen commented Stéphane Nicoll, when you fix this bug, please keep in mind that the regression naturally applies not only to a qualified transaction manager but also to a named transaction manager. For example, the Update to my previous comment: the solution is likely to rework the logic in the |
Stéphane Nicoll commented I confirm the problem with the qualifier but I don't see the problem with "named" transaction manager actually. If the default transaction manager is set, then I don't see what the "default transaction manager bean name" has to do with this: if you don't have a named transaction manager, you'll never go in that statement that caches the transaction manager. |
Stéphane Nicoll commented #16570 introduced a regression that when the "default" transaction This commit rework the "determineTransactionManager" condition to Also reworked the caching infrastructure so that a single cache holds |
Stéphane Nicoll commented This fix actually broke certain use cases where it is actually legit to return a |
Stéphane Nicoll commented Juergen Hoeller I think this one deserves a closer look on your end. Thanks! |
Stéphane Nicoll commented This fix broke yet another use case. If you are upgrading to Spring Framework 4.1.4 and your application throws the following exception, you may be affected:
An easy workaround to this issue is to mark your "main" A fix for this issue will be available in 4.1.5. If you're still affected with this workaround please create a separate issue with more details. Thanks! |
Chad Wilson commented Thanks for noting the workaround here Stéphane - confirmed that this resolve the issue for us on 4.1.4. |
Stéphane Nicoll commented Thanks for the feedback Chad, much appreciated! |
Donnchadh O Donnabhain opened SPR-12541 and commented
Status Quo
#16570 introduced caching of the default
PlatformTransactionManager
inTransactionAspectSupport
.Specifically, the
transactionManager
instance field is now set withindetermineTransactionManager()
. In subsequent invocations ofdetermineTransactionManager()
, the following if-logic at the beginning of the method results in the cached default transaction manager being returned instead of the transaction manager with the specified qualifier.Note, however, that the default transaction manager may have been set in Java Config due to the use of
TransactionManagementConfigurer
, or it may have been set in XML config viaTransactionProxyFactoryBean.setTransactionManager()
. Therefore, the behavior reported in this issue is not limited to caching of the default transaction manager indetermineTransactionManager()
. Rather, the behavior can be experienced any time thetransactionManager
field inTransactionAspectSupport
has been set.Steps to Reproduce
Given
and
... the default transaction manager will be used for invocations of
service.doBar()
rather thantransactionManager2
.Further Resources
See discussion on GitHub.
Affects: 4.1 GA
Issue Links:
@Transactional
/ tx:annotation-driven ("depends on")@Transactional
with and w/o qualifierReferenced from: commits 961574b, 4a0ac97, cec26e9
0 votes, 5 watchers
The text was updated successfully, but these errors were encountered: