Analysis of difficulties in Spring's transaction management (6): a special method is missing

In this section, we use specific examples to illustrate that dynamic proxies Based on CGLib bytecode cannot enjoy special methods for Spring AOP transaction enhancement.

01 <SPAN style = "FONT-SIZE: 14px; COLOR: #006600; FONT-FAMILY: Microsoft YaHei" minmax_bound = "true"> package com. baobaotao. special;

02 import org. springframework. stereotype. Service;

03 @ Service ("userService ")

04 public class UserService {

05

06 // ① The private method cannot be overwritten by the quilt due to access permission restrictions

07 private void method1 (){

08 System. out. println ("method1 ");

09}

10

11 // ② the final method cannot be overwritten by the quilt class

12 public final void method2 (){

13 System. out. println ("method2 ");

14}

15

16 // ③ static is a Class-level method and cannot be overwritten by the quilt class

17 public static void method3 (){

18 System. out. println ("method3 ");

19}

20

21 // ④ the public method can be overwritten by the quilt class, so it can be enhanced by dynamic bytecode

22 public void method4 (){

23 System. out. println ("method4 ");

24}

25} </SPAN>

Spring implements the key configuration of AOP transaction enhancement for UserService Bean through CGLib dynamic proxy technology, as shown below:

01 <SPAN style = "FONT-SIZE: 14px; COLOR: #006600; FONT-FAMILY: Microsoft YaHei" minmax_bound = "true">...

02 <aop: config proxy-target-class = "true"> <! -- ① Explicitly use CGLib dynamic proxy -->

03

04 <! -- ② Hope to implement transaction enhancement for all methods of UserService -->

05 <aop: pointcut id = "serviceJdbcMethod"

06 expression = "execution (* com. baobaotao. special. UserService. * (...)"/>

07 <aop: advisor pointcut-ref = "serviceJdbcMethod" advice-ref = "jdbcAdvice" order = "0"/>

08 </aop: config>

09 <tx: advice id = "jdbcAdvice" transaction-manager = "jdbcManager">

10 <tx: attributes>

11 <tx: method name = "*"/>

12 </tx: attributes>

13 </tx: advice>

14... </SPAN>

At ①, we explicitly use CGLib dynamic proxy technology through proxy-target-class = "true" and express all UserService methods through the AspjectJ cut-point expression at ②, we hope to implement Spring AOP transaction enhancement for all methods of UserService.
Add an executable method to UserService as follows:

01 <SPAN style = "FONT-SIZE: 14px; COLOR: #006600; FONT-FAMILY: Microsoft YaHei" minmax_bound = "true"> package com. baobaotao. special;

02 import org. springframework. context. ApplicationContext;

03 import org. springframework. context. support. ClassPathXmlApplicationContext;

04 import org. springframework. stereotype. Service;

05

06 @ Service ("userService ")

07 public class UserService {

08...

09 public static void main (String [] args ){

10 ApplicationContext ctx =

11 new ClassPathXmlApplicationContext ("user/special/applicationContext. xml ");

12 UserService service = (UserService) ctx. getBean ("userService ");

13

14 System. out. println ("before method1 ");

15 service. method1 ();

16 System. out. println ("after method1 ");

17

18 System. out. println ("before method2 ");

19 service. method2 ();

20 System. out. println ("after method2 ");

21

22 System. out. println ("before method3 ");

23 service. method3 ();

24 System. out. println ("after method3 ");

25

26 System. out. println ("before method4 ");

27 service. method4 ();

28 System. out. println ("after method4 ");

29

30}

31} </SPAN>

Before Running UserService, set the Log4J log level to DEBUG. Run the above Code to view the output log, as shown below:

Reference

① Transaction not enabled
Before method1
In method1
After method1

② Transactions not enabled
Before method2
In method2
After method2

③ Transactions not enabled
Before method3
In method3
After method3

④ Enable transactions
Before method4
Creating new transaction with name [com. baobaotao. special. UserService. method4]: PROPAGATION_REQUIRED, ISOLATION_DEFAULT
...
In method4
Initiating transaction commit
Committing JDBC transaction on Connection [jdbc: mysql: // localhost: 3306/sampledb, UserName = root @ localhost, MySQL-AB JDBC Driver]
Releasing JDBC Connection [jdbc: mysql: // localhost: 3306/sampledb, UserName = root @ localhost, MySQL-AB JDBC Driver] after transaction
Returning JDBC Connection to DataSource
After method4

⑤ Unused transactions
Before method5
In method5
After method5

⑥ Enable transactions
Before method6
Creating new transaction with name [com. baobaotao. special. UserService. method6]: PROPAGATION_REQUIRED, ISOLATION_DEFAULT
...
In method6
Initiating transaction commit
Committing JDBC transaction on Connection [jdbc: mysql: // localhost: 3306/sampledb, UserName = root @ localhost, MySQL-AB JDBC Driver]
...
After method6

 

Observe the above output logs and it is easy to find method1 ~ The four methods method3 and method5 were not implemented with Spring transaction enhancement, while method4 and method6 were implemented with transaction enhancement. This result demonstrates our previous discussion.
We use the following table to describe which special methods will become the fish of Spring AOP transaction enhancement.
Sn
Dynamic proxy Policy
Methods that cannot be enhanced by transactions
1. Interface-based Dynamic proxy all methods except public, and public static cannot be enhanced.
2 CGLib-based Dynamic proxy private, static, and final Methods

However, it should be noted that these special methods that cannot be enhanced by Spring transactions do not work in the transaction environment. As long as they are called by outer transaction methods, internal methods can also work in the transaction context started by external methods due to the propagation level of Spring transaction management. We say that these methods cannot be enhanced by Spring's AOP transaction, that is, they cannot start transactions, but the transaction context of the outer method can still be smoothly transmitted to these methods.
The only difference between these methods that cannot be enhanced by Spring transactions and those that can be enhanced by Spring transactions lies in "whether a new transaction can be started proactively": the former cannot be used but the latter can. For the transaction multicast behavior, the two are identical. The former and the latter do not cause data connection leakage. In other words, if these "special methods" are called by methods without the transaction context, they work in the non-transaction context; otherwise, if they are called by methods with the transaction context, then they work in the transaction context.
For private methods, since they are eventually encapsulated by the public method before being opened for external calls, and the public method can be enhanced by transactions, there is basically no problem. In actual development, the "public static" and "public final" special methods that are most likely to cause risks are the dynamic proxies Based on CGLib. The reason is that they are public, so they can be directly called by external classes (such as the Controller class of the Web layer), as long as the caller has no transactions listed below, these special methods also operate in a non-transactional manner.