I know this is a huge change, so I want to hear from the community.
A while ago, I was using the method security feature in Spring Security and I got this idea.
In Spring Security, Method Security is implemented through AOP, and these Aspects register their order by increasing 100 times in 100, 200, and 300 ways. (see -> org.springframework.security.authorization.method.AuthorizationManagerBeforeMethodInterceptor)
The problem is that the AOP that makes @Transactional work is located at the very end, which is the default order.
This means that if AccessDeniedException occurs in @PostAuthorizer, it will not be a rollback.
The official document explains how to change the order of @Transactional AOP to 0 to keep Method Security within the scope of the transaction.
(https://docs.spring.io/spring-security/reference/servlet/authorization/method-security.html#changing-the-order)
I think when users design an AOP function, the task of deciding whether the function is called within or outside the transaction will happen quite often.
However, if the Transactional AOP is located at the very end (by default), these settings become very difficult to set (because larger orders result in integer overflow)
So I'm suggesting carefully, how about putting the default order of @Transactional AOP to zero?
Comment From: quaff
I opened similar issue on boot side https://github.com/spring-projects/spring-boot/issues/27897.
Comment From: onjik
@quaff Thank you for your comment. 😀 I agree with most of them,
However, from the standpoint of creating a new framework, I think there is a problem when designing an AOP that is auto configured.
What should framework creators do if they want autoconfigured defaults to run in a transaction? Changing the transaction AOP order in the framework stage poses a high risk of conflict.
Comment From: snicoll
@onjik did you mean to close this?