Spring事务管理中@Transactional的propagation参数
关于Spring事务管理中@Transactional的其他配置问题,请参看http://deltamaster.is-programmer.com/posts/28488.html。
本文重点讲一讲propagation参数,propagation配置的就是一个事务的传播性问题。
所谓事务传播性,就是被调用者的事务与调用者的事务之间的关系。举例说明。
//in A.java Class A { @Transactional(propagation=propagation.REQUIRED) public void aMethod { B b = new B(); b.bMethod(); } } //in B.java Class B { @Transactional(propagation=propagation.REQUIRED) public void bMethod { //something } }
在上面这个例子中,传播性被设为了REQUIRED,注意,这是默认值,也即不进行该参数配置等于配置成REQUIRED。
REQUIRED的含义是,支持当前已经存在的事务,如果还没有事务,就创建一个新事务。在上面这个例子中,假设调用aMethod前不存在任何事务,那么执行aMethod时会自动开启一个事务,而由aMethod调用bMethod时,由于事务已经存在,因此会使用已经存在的事务(也就是执行aMethod之前创建的那个事务)。
对于这样的配置,如果bMethod过程中发生异常需要回滚,那么aMethod中所进行的所有数据库操作也将同时被回滚,因为这两个方法使用了同一个事务。
MANDATORY的含义是,支持当前已经存在的事务,如果还没有事务,就抛出一个异常。如果上例中aMethod的传播性配置为MANDATORY,我们就无法在没有事务的情况下调用aMethod,因此,传播性为MANDATORY的方法必定是一个其他事务的子事务,当逻辑上独立存在没有意义或者可能违反数据、事务完整性的时候,就可以考虑设置这样的传播性设置。
NESTED的含义是,在当前事务中创建一个嵌套事务,如果还没有事务,那么就简单地创建一个新事务。
REQUIRES_NEW的含义是,挂起当前事务,创建一个新事务,如果还没有事务,就简单地创建一个新事务。
请注意以上两者的区别,大多数情况下一上两种传播性行为是类似的,不过在事务回滚的问题上,以上两者有很大的区别。
首先,REQUIRES_NEW会创建一个与原事务无关的新事务,尽管是由一个事务调用了另一个事务,但却没有父子关系。
如果bMethod的传播性是REQUIRES_NEW,而抛出了一个异常,则bMethod一定会被回滚,而如果aMethod捕获并处理了这个bMethod抛出的异常,那么aMethod仍有可能成功提交。当然,如果aMethod没有处理这个异常,那么aMethod也会被回滚。
如果aMethod在bMethod完成后出现了异常,那么bMethod已经提交而无法回滚,只有aMethod被回滚了。
而对于NESTED,虽然也会创建一个新事务,但是这个事务与调用者是有父子关系的相互依存的。
如果bMethod的传播性是NESTED,而抛出了一个异常,事务的回滚行为与REQUIRES_NEW是一致的。
但是如果aMethod在bMethod完成后出现了异常,bMethod同样也会被回滚。因为事实上,EJB中没有对于NESTED传播性的类似实现,NESTED并不是真正启动了一个事务,而是开启了一个新的savepoint。
NEVER的含义很简单,就是强制要求不在事务中运行,如果当前存在一个事务,则抛出异常,因此如果bMethod传播性是NEVER,则一定抛出异常。
NOT_SUPPORTED的含义是,强制不在事务中运行,如果当前存在一个事务,则挂起该事务。
SUPPORTS的含义是,支持当前事务,如果没有事务那么就不在事务中运行。SUPPORTS传播性的逻辑含义比较模糊,因此一般是不推荐使用的。
Spring事务管理中@Transactional的参数配置
Spring作为低侵入的Java EE框架之一,能够很好地与其他框架进行整合,其中Spring与Hibernate的整合实现的事务管理是常用的一种功能。
所谓事务,就必须具备ACID特性,即原子性、一致性、隔离性和持久性,在Hibernate的实现中,需要我们编写代码来完成事务的控制工作。
public static void main(String[] args) { // Configuration cfg = new Configuration(); // cfg.configure(); // SessionFactory sf = cfg.buildSessionFactory(); //因为在HibernateUtil类中已经有一部分封装工作,所以以上三行注释掉了。 Session s = null; Transaction tx = null; try { Class.forName("com.HibernateUtil"); s = HibernateUtil.getSession(); tx = s.beginTransaction(); //这里开启了事务 //事务中所需的一系列数据库操作。 tx.commit(); } catch (HibernateException e) { //如果出现异常,且事务已经开启,则需要回滚。 if (tx != null) tx.rollback(); throw e; } catch (ClassNotFoundException e) { e.printStackTrace(); } finally { //无论如何都需要关闭Session。 if (s != null) s.close(); } //sf.close(); System.out.println("end"); }
上面的代码大致就是事务控制的一般思路,那么,由于此事务的管理具有一定的共性,我们就更倾向于使用Spring帮助我们来完成事务管理工作,具体配置方式不是本文的重点,大家可以查看其他文章。有以下两点需要重点注意:
- @Transactional注解就代表支持事务管理,如果这个注解在类上,那么表示该注解对于所有该类中的public方法都生效;如果注解出现在方法上,则代表该注解仅对该方法有效,会覆盖先前从类层次继承下来的注解。
- 一般情况下不要将这个注解加到接口和抽象类上,因为注解是不能被继承的。
本文主要讲使用注解方式配置事务管理时@Transactional的各种参数配置问题。
- propagation参数,Propagation类型(枚举),默认值为Propogation.REQUIRED,支持的值有REQUIRED、MANDATORY、NESTED、NEVER、NOT_SUPPORTED、REQUIRE_NEW、SUPPORTS。关于这个问题的详细说明将在以后的文章中展开。
- isolation参数,Isolation类型(枚举),默认值为Isolation.DEFAULT,支持的值有DEFAULT、READ_COMMITTED、READ_UNCOMMITTED、REPEATABLE_READ、SERIALIZABLE。关于这个问题的详细说明将在以后的文章中展开。
- timeout参数,int类型,事务的超时时间,默认值为-1,即不会超时。
- readOnly参数,boolean类型,true表示事务为只读,默认值为false。
- rollbackFor参数,Class<? extends Throwable>[]类型,默认为空数组。
- rollbackForClassName参数,String[]类型,默认为空数组。
- noRollbackFor参数,Class<? extends Throwable>[]类型,默认为空数组。
- noRollbackForClassName参数,String[]类型,默认为空数组。
最后四个参数都与回滚有关,首先,一般不推荐使用rollbackForClassName和noRollbackForClassName两个参数,而用另外两个参数来代替,从参数的类型上就可以看出区别,使用字符串的缺点在于:如果不是用类的完整路径,就可能导致回滚设置对位于不同包中的同名类都生效;且如果类名写错,也无法得到IDE的动态提示。
但是,如果不配置任何与回滚有关的参数,不代表事务不会进行回滚,如果没有配置这四个选项,那么DefaultTransactionAttribute配置将会生效,具体的行为是,抛掷任何unchecked Exception都会触发回滚,当然包括所有的RuntimeException。