-
Notifications
You must be signed in to change notification settings - Fork 38.2k
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 does not work on package protected methods of CGLib proxies #25582
Comments
FWIW, the TestContext framework actually sets the flag to Line 151 in 13183c8
I'd be in favor of making production changes here (as an opt-in feature). In light of that, I've added the |
I really don't think it should be an opt-in fix as it currently creates an inconsistency in the applicability of annotations to methods as shown above. Also, you don't have to explicitly enable this for other annotations, why would you have to in this particular case? I guess the reason that this has been overseen for so long is that folks are used to make everything and the world |
Then perhaps an opt-in feature for switching it back to the old way, in case the change causes issues for some projects.
Yes, I agree. |
Another user stumbling over this: https://stackoverflow.com/questions/63675153/transactional-annotation-doesnt-solve-org-hibernate-lazyinitializationexception |
Here's how I currently work around the issue in a project. I get hold of the |
AnnotationTransactionAttributeSource
contains a flag whether to only consider public methods, set totrue
by default. I assume that stems from the times when JDK proxies where the primary way of applying proxies and with those only public methods can be intercepted anyway.With CGLib proxies this is different. Package private methods can be invoked on the proxy and properly make their way through the AOP infrastructure. However, the lookup of transaction attributes is eagerly aborted due to the flag mentioned above. This creates confusing situations (assume
@EnableGlobalMethodSecurity
and@EnableTransactionManagement
applied):In this example, the security annotations are applied as the security infrastructure does not work with a flag like this and the advice is registered for the method invocation. The transactional annotations are not applied, as the method is not inspected for transactional annotations in the first place.
I wonder if it makes sense to flip the flag based on the
proxyTargetClass
attribute in@EnableTransactionManagement
. If that is set to true, CGLib proxies are created and thus, transaction annotations should be regarded on package protected methods. This seems to be especially important in the context of Spring Boot setting this flag totrue
by default.A current workaround is demonstrated in this commit, which uses a
PriorityOrdered
BeanPostProcessor
to reflectively flip the flag, not considering any configuration as in that particular case we know we're always gonna run with CGLib proxies.The text was updated successfully, but these errors were encountered: