[总结]Spring事务管理中@Transactional的参数

Mobabel · · 2702 次点击 · · 开始浏览

这是一个创建于的文章，其中的信息可能已经有所发展或是发生改变。

@Transactional注解就代表支持事务管理，@Transactional 注解可以被应用于接口定义和接口方法、类定义和类的 public 方法上。如果这个注解在类上，那么表示该注解对于所有该类中的public方法都生效；如果注解出现在方法上，则代表该注解仅对该方法有效，会覆盖先前从类层次继承下来的注解。
@Transactional 注解只能应用到 public 可见度的方法上。如果你在 protected、private 或者 package-visible 的方法上使用 @Transactional 注解，它也不会报错，但是这个被注解的方法将不会展示已配置的事务设置。
注意仅仅 @Transactional 注解的出现不足于开启事务行为，它仅仅是一种元数据。必须在配置文件中使用配置元素，才真正开启了事务行为。
通过元素的 “proxy-target-class” 属性值来控制是基于接口的还是基于类的代理被创建。如果 “proxy-target-class” 属值被设置为 “true”，那么基于类的代理将起作用（这时需要CGLIB库cglib.jar在CLASSPATH中）。如果 “proxy-target-class” 属值被设置为 “false” 或者这个属性被省略，那么标准的JDK基于接口的代理将起作用。
Spring团队建议在具体的类（或类的方法）上使用 @Transactional 注解，而不要使用在类所要实现的任何接口上。在接口上使用 @Transactional 注解，只能当你设置了基于接口的代理时它才生效。一般情况下不要将这个注解加到接口和抽象类上，因为注解是不能被继承的。这就意味着如果正在使用基于类的代理时，那么事务的设置将不能被基于类的代理所识别，而且对象也将不会被事务代理所包装。
@Transactional 的事务开启，或者是基于接口的或者是基于类的代理被创建。所以在同一个类中一个方法直接调用另一个方法有事务的方法，事务是不会起作用的。

@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[]类型，默认为空数组。

rollback

最后四个参数都与回滚有关，首先，一般不推荐使用rollbackForClassName和noRollbackForClassName两个参数，而用另外两个参数来代替，从参数的类型上就可以看出区别，使用字符串的缺点在于：如果不是用类的完整路径，就可能导致回滚设置对位于不同包中的同名类都生效；且如果类名写错，也无法得到IDE的动态提示。

但是，如果不配置任何与回滚有关的参数，不代表事务不会进行回滚，如果没有配置这四个选项，那么DefaultTransactionAttribute配置将会生效，具体的行为是，抛掷任何unchecked Exception都会触发回滚，当然包括所有的RuntimeException。

isolation

isolation的参数有以下五种：

1. Isolation.DEFAULT:为数据源的默认隔离级别

2. isolation=Isolation.READ_UNCOMMITTED:未授权读取级别

以操作同一行数据为前提，读事务允许其他读事务和写事务，未提交的写事务禁止其他写事务（但允许其他读事务）。此隔离级别可以防止更新丢失，但不能防止脏读、不可重复读、幻读。此隔离级别可以通过“排他写锁”实现。

3. iIsolation.READ_COMMITTED:授权读取级别

以操作同一行数据为前提，读事务允许其他读事务和写事务，未提交的写事务禁止其他读事务和写事务。此隔离级别可以防止更新丢失、脏读，但不能防止不可重复读、幻读。此隔离级别可以通过“瞬间共享读锁”和“排他写锁”实现。

4. iIsolation.REPEATABLE_READ:可重复读取级别

以操作同一行数据为前提，读事务禁止其他写事务（但允许其他读事务），未提交的写事务禁止其他读事务和写事务。此隔离级别可以防止更新丢失、脏读、不可重复读，但不能防止幻读。此隔离级别可以通过“共享读锁”和“排他写锁”实现。

5. iIsolation.SERIALIZABLE:序列化级别

提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，不能并发执行。此隔离级别可以防止更新丢失、脏读、不可重复读、幻读。如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。

隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为READ_COMMITTED。它能够避免更新丢失、脏读，而且具有较好的并发性能。尽管它会导致不可重复读、幻读这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。

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 }
}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

//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传播性的逻辑含义比较模糊，因此一般是不推荐使用的。