Spring的事务管理难点剖析(6):特殊方法成漏网之鱼
程序员文章站
2022-04-16 17:01:38
...
哪些方法不能实施Spring AOP事务
由于Spring事务管理是基于接口代理或动态字节码技术,通过AOP实施事务增强的。虽然Spring还支持AspectJ LTW在类加载期实施增强,但这种方法很少使用,所以我们不予关注。
对于基于接口动态代理的AOP事务增强来说,由于接口的方法都必然是public的,这就要求实现类的实现方法也必须是public的(不能是protected、private等),同时不能使用static的修饰符。所以,可以实施接口动态代理的方法只能是使用“public”或“public final”修饰符的方法,其他方法不可能被动态代理,相应的也就不能实施AOP增强,换句话说,即不能进行Spring事务增强了。
基于CGLib字节码动态代理的方案是通过扩展被增强类,动态创建其子类的方式进行AOP增强植入的。由于使用final、static、private修饰符的方法都不能被子类覆盖,相应的,这些方法将无法实施AOP增强。所以方法签名必须特别注意这些修饰符的使用,以免使方法不小心成为事务管理的漏网之鱼。
事务增强遗漏实例
本节中,我们通过具体的实例说明基于CGLib字节码动态代理无法享受Spring AOP事务增强的特殊方法。
Spring通过CGLib动态代理技术对UserService Bean实施AOP事务增强的关键配置,具体如下所示:
在①处,我们通过proxy-target-class="true"显式使用CGLib动态代理技术,在②处通过AspjectJ切点表达式表达UserService所有的方法,希望对UserService所有方法都实施Spring AOP事务增强。
在UserService添加一个可执行的方法,如下所示:
在运行UserService之前,将Log4J日志级别设置为DEBUG,运行以上代码查看输出日志,如下所示:
①未启用事务
before method1
in method1
after method1
②未启用事务
before method2
in method2
after method2
③未启用事务
before method3
in method3
after method3
④启用事务
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
⑤未用事务
before method5
in method5
after method5
⑥启用事务
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
观察以上输出日志,很容易发现method1~method3及method5这4个方法都没有被实施Spring的事务增强,而method4和method6被实施了事务增强。这个结果验证了我们前面的论述。
我们通过下表描述哪些特殊方法将成为Spring AOP事务增强的漏网之鱼。
不过,需要特别指出的是,这些不能被Spring事务增强的特殊方法并非就不工作在事务环境下。只要它们被外层的事务方法调用了,由于Spring事务管理的传播级别,内部方法也可以工作在外部方法所启动的事务上下文中。我们说,这些方法不能被Spring进行AOP事务增强,是指这些方法不能启动事务,但是外层方法的事务上下文依旧可以顺利地传播到这些方法中。
这些不能被Spring事务增强的方法和可被Spring事务增强的方法唯一的区别在于“是否可以主动启动一个新事务”:前者不能而后者可以。对于事务传播行为来说,二者是完全相同的,前者也和后者一样不会造成数据连接的泄漏问题。换句话说,如果这些“特殊方法”被无事务上下文的方法调用,则它们就工作在无事务上下文中;反之,如果被具有事务上下文的方法调用,则它们就工作在事务上下文中。
对于private的方法,由于最终都会被public方法封装后再开放给外部调用,而public方法是可以被事务增强的,所以基本上没有什么问题。在实际开发中,最容易造成隐患的是基于CGLib的动态代理时的“public static”和“public final”这两种特殊方法。原因是它们本身是public的,因此可以直接被外部类(如Web层的Controller类)调用,只要调用者没有事务上下文,这些特殊方法也就以无事务的方式运作。
注:以上内容摘自《Spring 4.x企业应用开发实战》
由于Spring事务管理是基于接口代理或动态字节码技术,通过AOP实施事务增强的。虽然Spring还支持AspectJ LTW在类加载期实施增强,但这种方法很少使用,所以我们不予关注。
对于基于接口动态代理的AOP事务增强来说,由于接口的方法都必然是public的,这就要求实现类的实现方法也必须是public的(不能是protected、private等),同时不能使用static的修饰符。所以,可以实施接口动态代理的方法只能是使用“public”或“public final”修饰符的方法,其他方法不可能被动态代理,相应的也就不能实施AOP增强,换句话说,即不能进行Spring事务增强了。
基于CGLib字节码动态代理的方案是通过扩展被增强类,动态创建其子类的方式进行AOP增强植入的。由于使用final、static、private修饰符的方法都不能被子类覆盖,相应的,这些方法将无法实施AOP增强。所以方法签名必须特别注意这些修饰符的使用,以免使方法不小心成为事务管理的漏网之鱼。
事务增强遗漏实例
本节中,我们通过具体的实例说明基于CGLib字节码动态代理无法享受Spring AOP事务增强的特殊方法。
package com.baobaotao.special; import org.springframework.stereotype.Service; @Service("userService") public class UserService { //① private方法因访问权限的限制,无法被子类覆盖 private void method1() { System.out.println("method1"); } //② final方法无法被子类覆盖 public final void method2() { System.out.println("method2"); } //③ static是类级别的方法,无法被子类覆盖 public static void method3() { System.out.println("method3"); } //④ public方法可以被子类覆盖,因此可以被动态字节码增强 public void method4() { System.out.println("method4"); } }
Spring通过CGLib动态代理技术对UserService Bean实施AOP事务增强的关键配置,具体如下所示:
… <aop:config proxy-target-class="true"><!-- ①显式使用CGLib动态代理 --> <!-- ②希望对UserService所有方法实施事务增强 --> <aop:pointcut id="serviceJdbcMethod" expression="execution(* com.baobaotao.special.UserService.*(..))"/> <aop:advisor pointcut-ref="serviceJdbcMethod" advice-ref="jdbcAdvice" order="0"/> </aop:config> <tx:advice id="jdbcAdvice" transaction-manager="jdbcManager"> <tx:attributes> <tx:method name="*"/> </tx:attributes> </tx:advice> …
在①处,我们通过proxy-target-class="true"显式使用CGLib动态代理技术,在②处通过AspjectJ切点表达式表达UserService所有的方法,希望对UserService所有方法都实施Spring AOP事务增强。
在UserService添加一个可执行的方法,如下所示:
package com.baobaotao.special; import org.springframework.context.ApplicationContext; import org.springframework.context.support.ClassPathXmlApplicationContext; import org.springframework.stereotype.Service; @Service("userService") public class UserService { … public static void main(String[] args) { ApplicationContext ctx = new ClassPathXmlApplicationContext("user/special/applicationContext.xml"); UserService service = (UserService) ctx.getBean("userService"); System.out.println("before method1"); service.method1(); System.out.println("after method1"); System.out.println("before method2"); service.method2(); System.out.println("after method2"); System.out.println("before method3"); service.method3(); System.out.println("after method3"); System.out.println("before method4"); service.method4(); System.out.println("after method4"); } }
在运行UserService之前,将Log4J日志级别设置为DEBUG,运行以上代码查看输出日志,如下所示:
引用
①未启用事务
before method1
in method1
after method1
②未启用事务
before method2
in method2
after method2
③未启用事务
before method3
in method3
after method3
④启用事务
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
⑤未用事务
before method5
in method5
after method5
⑥启用事务
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
观察以上输出日志,很容易发现method1~method3及method5这4个方法都没有被实施Spring的事务增强,而method4和method6被实施了事务增强。这个结果验证了我们前面的论述。
我们通过下表描述哪些特殊方法将成为Spring AOP事务增强的漏网之鱼。
序 号 | 动态代理策略 | 不能被事务增强的方法 |
1 | 基于接口的动态代理 | 除public外的其他所有的方法,此外public static也不能被增强 |
2 | 基于CGLib的动态代理 | private、static、final的方法 |
不过,需要特别指出的是,这些不能被Spring事务增强的特殊方法并非就不工作在事务环境下。只要它们被外层的事务方法调用了,由于Spring事务管理的传播级别,内部方法也可以工作在外部方法所启动的事务上下文中。我们说,这些方法不能被Spring进行AOP事务增强,是指这些方法不能启动事务,但是外层方法的事务上下文依旧可以顺利地传播到这些方法中。
这些不能被Spring事务增强的方法和可被Spring事务增强的方法唯一的区别在于“是否可以主动启动一个新事务”:前者不能而后者可以。对于事务传播行为来说,二者是完全相同的,前者也和后者一样不会造成数据连接的泄漏问题。换句话说,如果这些“特殊方法”被无事务上下文的方法调用,则它们就工作在无事务上下文中;反之,如果被具有事务上下文的方法调用,则它们就工作在事务上下文中。
对于private的方法,由于最终都会被public方法封装后再开放给外部调用,而public方法是可以被事务增强的,所以基本上没有什么问题。在实际开发中,最容易造成隐患的是基于CGLib的动态代理时的“public static”和“public final”这两种特殊方法。原因是它们本身是public的,因此可以直接被外部类(如Web层的Controller类)调用,只要调用者没有事务上下文,这些特殊方法也就以无事务的方式运作。
注:以上内容摘自《Spring 4.x企业应用开发实战》