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

声明式事务总结

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

 

 

@Transactional的各种参数配置问题。

1. propagation参数，Propagation类型（枚举），默认值为Propogation.REQUIRED，支持的值有REQUIRED、MANDATORY、NESTED、NEVER、NOT_SUPPORTED、REQUIRE_NEW、SUPPORTS。
2. isolation参数，Isolation类型（枚举），默认值为Isolation.DEFAULT，支持的值有DEFAULT、READ_COMMITTED、READ_UNCOMMITTED、REPEATABLE_READ、SERIALIZABLE。
3. timeout参数，int类型，事务的超时时间，默认值为-1，即不会超时。
4. readOnly参数，boolean类型，true表示事务为只读，默认值为false。
5. rollbackFor参数，Class<? extends Throwable>[]类型，默认为空数组。
6. rollbackForClassName参数，String[]类型，默认为空数组。
7. noRollbackFor参数，Class<? extends Throwable>[]类型，默认为空数组。
8. noRollbackForClassName参数，String[]类型，默认为空数组。

1. rollback

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

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

2. isolation

isolation的参数有以下五种：

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

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

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

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

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

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

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

5. iIsolation.SERIALIZABLE:序列化级别

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

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

3. propagation

Propagation配置的就是一个事务的传播性问题。所谓事务传播性，就是被调用者的事务与调用者的事务之间的关系。举例说明。

在上面这个例子中，传播性被设为了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传播性的逻辑含义比较模糊，因此一般是不推荐使用的。

 

4. (补充)为什么编程式优于声明式

编程式事务

基于底层的API，如PlatformTransactionManager、TransactionDefinition 和 TransactionTemplate 等核心接口，开发者完全可以通过编程的方式来进行事务管理。

编程式事务方式需要是开发者在代码中手动的管理事务的开启、提交、回滚等操作。

public void test() { TransactionDefinition def = new DefaultTransactionDefinition(); TransactionStatus status = transactionManager.getTransaction(def); try { // 事务操作 // 事务提交 transactionManager.commit(status); } catch (DataAccessException e) { // 事务提交 transactionManager.rollback(status); throw e; } }

1 2 3 4 5 6 7 8 9 10 11 12 13 14

public void test() {       TransactionDefinition def = new DefaultTransactionDefinition();       TransactionStatus status = transactionManager.getTransaction(def);        try {          // 事务操作            // 事务提交          transactionManager.commit(status);       } catch (DataAccessException e) {          // 事务提交          transactionManager.rollback(status);          throw e;       } }

声明式事务的优点

通过上面的例子，其实我们可以很容易的看出来，声明式事务帮助我们节省了很多代码，他会自动帮我们进行事务的开启、提交以及回滚等操作，把程序员从事务管理中解放出来。

声明式事务管理使用了 AOP 实现的，本质就是在目标方法执行前后进行拦截。 在目标方法执行前加入或创建一个事务，在执行方法执行后，根据实际情况选择提交或是回滚事务。

使用这种方式，对代码没有侵入性，方法内只需要写业务逻辑就可以了。

但是，声明式事务真的有这么好么？倒也不见得。

声明式事务的粒度问题

首先，声明式事务有一个局限，那就是他的最小粒度要作用在方法上。

也就是说，如果想要给一部分代码块增加事务的话，那就需要把这个部分代码块单独独立出来作为一个方法。

但是，正是因为这个粒度问题，本人并不建议过度的使用声明式事务。

首先，因为声明式事务是通过注解的，有些时候还可以通过配置实现，这就会导致一个问题，那就是这个事务有可能被开发者忽略。

事务被忽略了有什么问题呢？

首先，如果开发者没有注意到一个方法是被事务嵌套的，那么就可能会再方法中加入一些如RPC远程调用、消息发送、缓存更新、文件写入等操作。

我们知道，这些操作如果被包在事务中，有两个问题：

1、这些操作自身是无法回滚的，这就会导致数据的不一致。可能RPC调用成功了，但是本地事务回滚了，可是PRC调用无法回滚了。

2、在事务中有远程调用，就会拉长整个事务。那么久会导致本事务的数据库连接一直被占用，那么如果类似操作过多，就会导致数据库连接池耗尽。

有些时候，即使没有在事务中进行远程操作，但是有些人还是可能会不经意的进行一些内存操作，如运算。或者如果遇到分库分表的情况，有可能不经意间进行跨库操作。

但是如果是编程式事务的话，业务代码中就会清清楚楚看到什么地方开启事务，什么地方提交，什么时候回滚。这样有人改这段代码的时候，就会强制他考虑要加的代码是否应该方法事务内。

有些人可能会说，已经有了声明式事务，但是写代码的人没注意，这能怪谁。

话虽然是这么说，但是我们还是希望可以通过一些机制或者规范，降低这些问题发生的概率。

比如建议大家使用编程式事务，而不是声明式事务。因为，作者工作这么多年来，发生过不止一次开发者没注意到声明式事务而导致的故障。

因为有些时候，声明式事务确实不够明显。

除了事务的粒度问题，还有一个问题那就是声明式事务虽然看上去帮我们简化了很多代码，但是一旦没用对，也很容易导致事务失效。

如以下几种场景就可能导致声明式事务失效：

1. @Transactional 应用在非 public 修饰的方法上
2. @Transactional 注解属性 propagation 设置错误
3. @Transactional 注解属性 rollbackFor 设置错误
4. 同一个类中方法调用，导致@Transactional失效
5. 异常被catch捕获导致@Transactional失效
6. 数据库引擎不支持事务

以上几个问题，如果使用编程式事务的话，很多都是可以避免的。

使用声明事务失效的问题我们发生过很多次。不知道大家有没有遇到过，我是实际遇到过的

因为Spring的事务是基于AOP实现的，但是在代码中，有时候我们会有很多切面，不同的切面可能会来处理不同的事情，多个切面之间可能会有相互影响。

在之前的一个项目中，我就发现我们的Service层的事务全都失效了，一个SQL执行失败后并没有回滚，排查下来才发现，是因为一位同事新增了一个切面，这个切面里面做个异常的统一捕获，导致事务的切面没有捕获到异常，导致事务无法回滚。

这样的问题，发生过不止一次，而且不容易被发现。

很多人还是会说，说到底还是自己能力不行，对事务理解不透彻，用错了能怪谁。

但是我还是那句话，我们确实无法保证所有人的能力都很高，也无法要求所有开发者都能不出错。我们能做的就是，尽量可以通过机制或者规范，来避免或者降低这些问题发生的概率。

其实，如果大家有认真看过阿里巴巴出的那份Java开发手册的话，其实就能发现，其中的很多规约并不是完完全全容易被人理解，有些也比较生硬，但是其实，这些规范都是从无数个坑里爬出来的开发者们总结出来的。

 

[source]

Spring事务管理中@Transactional的参数配置

Spring事务管理中@Transactional的propagation参数

spring 事务-使用@Transactional 注解（事务隔离级别）

Spring官方都推荐使用的@Transactional事务，为啥我不建议使用！