@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");
before method1 method1 after method1 before method2 method2 after method2 before method3 method3 after method3 before method4
17:24:10,953 (AbstractPlatformTransactionManager.java:365) - Creating new transaction with name [user.special.UserService.method4]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
17:24:11,109 (DataSourceTransactionManager.java:205) - Acquired Connection [org.apache.commons.dbcp.PoolableConnection@165b7e] for JDBC transaction
…
17:24:11,109 (DataSourceTransactionManager.java:265) - Committing JDBC transaction on Connection [org.apache.commons.dbcp.PoolableConnection@165b7e]
17:24:11,125 (DataSourceTransactionManager.java:323) - Releasing JDBC Connection [org.apache.commons.dbcp.PoolableConnection@165b7e] after transaction
17:24:11,125 (DataSourceUtils.java:312) - Returning JDBC Connection to DataSource
after method4 观察以上输出日志,很容易发现 method1~method3 这 3 个方法都没有被实施 Spring 的事务增强,只有 method4 被实施了事务增强。这个结果刚才验证了我们前面的论述。 我们通过下表描述哪些特殊方法将成为 Spring AOP 事务增强的漏网之鱼: 表 2. 不能被 Spring AOP 事务增强的方法 动态代理策略 不能被事务增强的方法 基于接口的动态代理 除 public 外的其它所有的方法,此外 public static 也不能被增强 基于 CGLib 的动态代理 private、static、final 的方法 不过,需要特别指出的是,这些不能被 Spring 事务增强的特殊方法并非就不工作在事务环境下。只要它们被外层的事务方法调用了,由于 Spring 的事务管理的传播特殊,内部方法也可以工作在外部方法所启动的事务上下文中。我们说,这些方法不能被 Spring 进行 AOP 事务增强,是指这些方法不能启动事务,但是外层方法的事务上下文依就可以顺利地传播到这些方法中。 这些不能被 Spring 事务增强的方法和可被 Spring 事务增强的方法唯一的区别在 “是否可以主动启动一个新事务”:前者不能而后者可以。对于事务传播行为来说,二者是完全相同的,前者也和后者一样不会造成数据连接的泄漏问题。换句话说,如果这些“特殊方法”被无事务上下文的方法调用,则它们就工作在无事务上下文中;反之,如果被具有事务上下文的方法调用,则它们就工作在事务上下文中。 对于 private 的方法,由于最终都会被 public 方法封装后再开放给外部调用,而 public 方法是可以被事务增强的,所以基本上没有什么问题。在实际开发中,最容易造成隐患的是基于 CGLib 的动态代理时的“public static”和“public final”这两种特殊方法。原因是它们本身是 public 的,所以可以直接被外部类(如 Web 层的 Controller 类)调用,只要调用者没有事务上下文,这些特殊方法也就以无事务的方式运作。