Spring 声明式事务常用的二种配置方式
声明式事务管理建立在AOP之上的。其本质是对方法前后进行拦截,然后在目标方法开始之前创建或者加入一个事务,在执行完目标方法之后根据执行情况提交或者回滚事务。声明式事务最大的优点就是不需要通过编程的方式管理事务,这样就不需要在业务逻辑代码中掺杂事务管理的代码,只需在配置文件中做相关的事务规则声明(或通过基于@Transactional注解的方式),便可以将事务规则应用到业务逻辑中。
显然声明式事务管理要优于编程式事务管理,这正是spring倡导的非侵入式的开发方式。声明式事务管理使业务代码不受污染,一个普通的POJO对象,只要加上注解就可以获得完全的事务支持。和编程式事务相比,声明式事务唯一不足地方是,后者的最细粒度只能作用到方法级别,无法做到像编程式事务那样可以作用到代码块级别。但是即便有这样的需求,也存在很多变通的方法,比如,可以将需要进行事务管理的代码块独立为方法等等。
1. 一种是基于tx和aop名字空间的xml配置文件,核心配置如下:
2. 基于@Transactional注解,核心配置如下:
总结:二种方式都能有效利用Spring的事务管理机制来管理事务的ACID,这里在项目中要使用那种方式还需要一定的取舍;首先我们来分析第一种,第一种主要是采用Aop+xml的配置,这种方式主要是在xml中配置Aop的切入点(就是service中的方法)和配置哪些方法需要加入事务管理,通常用正则匹配的方式,且核心的配置信息(事务控制)都是配置在xml中;而第二种是Aop+annotation的,这种方式是利用Aop去扫描带@Transactional的注解的方法,并在该方法之前按照注解配置的事务控制规则来进行事务的管理。当业务中出现需要批量的设置方法的事务控制规则的时候推荐使用第一种,反之都选择选择第二种,而第二种是需要在每个需要事务控制的方法上都加入注解,但由于第一种控制的是所有方法,第二种是控制的指定方法,这个时候第一种的开销肯定要比第二种大,还有就是需要了解事务隔离级别,要考虑在指定业务上要怎么能保证数据的ACID,这样才能在代码中更好的设置对应的事务控制规则,还有就是千万不要在同一个项目中使用了带二种方式的事务配置(没意义),它们功能是一样的,使用一种就行。