【Spring】浅谈Spring事务

1、事务概述

1.1、事务的特性

• 原子性（Atomicity）：事务是一个不可再分割的工作单位，事务中的操作要么都执行，要么都不执行
  例如：A给B转账，如果B的账户操作失败，则本次交易失败，A和B的账户都不会进行修改。
• 一致性（Consistency）：在执行一个事务前和后，数据库的完整性约束都没有被破坏。也就是说事务不能破坏数据库的完整性以及业务逻辑的一致性。例如业务逻辑一致性：A给B转账，无论是否操作成功，两者的账户余额之和应该是不变的。转账前后数据库的约束关系依旧是正确不变的，例如唯一索引，主键等。
• 隔离性（Isolation）：多个事务并发时，每个事务应该是隔离的，一个事务不应影响其他事务的运行效果。在并发环境当中，当不同的事务访问相同的数据时，每个事务都有各自的完整的数据空间，由于并发事务所做的修改必须与并发的其他事务的修改隔离，所以事务查看数据更新时，数据所处的状态要么是另一个事务开始前的状态，要么就是另一个事务结束后的状态，不会查看到中间状态数据。
• 持久性（Durability）：当一个事提交后，对数据库的改变是永久性的，不会被回滚。

1.2、事务的隔离级别

事务的隔离级别定义一个事务可能受其他并发事务活动影响的程度。

在一个典型的应用程序中，多个事务同时运行，经常会为了完成他们的工作而操作同一个数据。并发虽然是必需的，但是会导致以下问题：

• 脏读（Dirty read）
  脏读发生在一个事务读取了被另一个事务改写但尚未提交的数据时。如果这些改变在稍后被回滚了，那么第一个事务读取的数据就会是无效的。
• 不可重复读（Nonrepeatable read）
  不可重复读发生在一个事务内连续执行两次或以上相同查询时，出现每次查询结果却不相同的情况。这通常是由于另一个并发事务在两次查询之间更新了数据。

不可重复读重点在修改

• 幻读（Phantom reads）
  幻读和不可重复读相似。发生在一个事务内执行两次或以上相同读取操作时，每次读取的到记录数量有差异。

幻读重点在新增或删除。

隔离级别	含义
READ_UNCOMMITTED	允许读取尚未提交的更改。可能导致脏读、幻读或不可重复读。
READ_COMMITTED	（Oracle 默认级别）允许从已经提交的并发事务读取。可防止脏读，但幻读和不可重复读仍可能会发生。
REPEATABLE_READ	（MYSQL默认级别）对相同字段的多次读取的结果是一致的，除非数据被当前事务本身改变。可防止脏读和不可重复读，但幻读仍可能发生。
SERIALIZABLE	完全服从ACID的隔离级别，确保不发生脏读、不可重复读和幻影读。这在所有隔离级别中也是最慢的，因为它通常是通过完全锁定当前事务所涉及的数据表来完成的。

注：黄色代表oracle数据库的隔离级别

2、Spring支持的事务管理方式

2.1、编程式事务管理

编程式事务管理是侵入性事务管理，使用TransactionTemplate或者直接使用PlatformTransactionManager，对于编程式事务管理，Spring推荐使用TransactionTemplate。

2.2、声明式事务管理

声明式事务管理建立在AOP之上，其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，执行完目标方法之后根据执行的情况提交或者回滚。
编程式事务每次实现都要单独实现，但业务量大功能复杂时，使用编程式事务无疑是痛苦的，而声明式事务不同，声明式事务属于无侵入式，不会影响业务逻辑的实现，只需要在配置文件中做相关的事务规则声明或者通过注解的方式，便可以将事务规则应用到业务逻辑中。
显然声明式事务管理要优于编程式事务管理，这正是Spring倡导的无侵入式的编程方式。唯一不足的地方就是声明式事务管理的粒度是方法级别，而编程式事务管理是可以到代码块的，但是可以通过提取方法的方式完成声明式事务管理的配置。

2.3、事务的传播机制

事务的传播性一般用在事务嵌套的场景，比如一个事务方法里面调用了另外一个事务方法，那么两个方法是各自作为独立的方法提交还是内层的事务合并到外层的事务一起提交，这就是需要事务传播机制的配置来确定怎么样执行。
常用的事务传播机制如下：

• propagation_required
  Spring默认的传播机制，能满足绝大部分业务需求，如果外层有事务，则当前事务加入到外层事务，一块提交，一块回滚。如果外层没有事务，新建一个事务执行
• propagation_requires_new
  该事务传播机制是每次都会新开启一个事务，同时把外层事务挂起，当当前事务执行完毕，恢复上层事务的执行。如果外层没有事务，执行当前新开启的事务即可
• propagation_support
  如果外层有事务，则加入外层事务，如果外层没有事务，则直接使用非事务方式执行。完全依赖外层的事务
• propagation_not_support
  该传播机制不支持事务，如果外层存在事务则挂起，执行完当前代码，则恢复外层事务，无论是否异常都不会回滚当前的代码
• propagation_never
  该传播机制不支持外层事务，即如果外层有事务就抛出异常
• propagation_mandatory
  与NEVER相反，如果外层没有事务，则抛出异常
• propagation_nested
  该传播机制的特点是可以保存状态保存点，当前事务回滚到某一个点，从而避免所有的嵌套事务都回滚，即各自回滚各自的，如果子事务没有把异常吃掉，基本还是会引起全部回滚的。

传播规则回答了这样一个问题：一个新的事务应该被启动还是被挂起，或者是一个方法是否应该在事务性上下文中运行。

2.4、只读

如果一个事务只对数据库执行读操作，那么该数据库就可能利用那个事务的只读特性，采取某些优化措施。通过把一个事务声明为只读，可以给后端数据库一个机会来应用那些它认为合适的优化措施。由于只读的优化措施是在一个事务启动时由后端数据库实施的， 因此，只有对于那些具有可能启动一个新事务的传播行为（PROPAGATION_REQUIRES_NEW、PROPAGATION_REQUIRED、 ROPAGATION_NESTED）的方法来说，将事务声明为只读才有意义。

2.5、事务超时

为了使一个应用程序很好地执行，它的事务不能运行太长时间。因此，声明式事务的下一个特性就是它的超时。

假设事务的运行时间变得格外的长，由于事务可能涉及对数据库的锁定，所以长时间运行的事务会不必要地占用数据库资源。这时就可以声明一个事务在特定秒数后自动回滚，不必等它自己结束。

由于超时时钟在一个事务启动的时候开始的，因此，只有对于那些具有可能启动一个新事务的传播行为（PROPAGATION_REQUIRES_NEW、PROPAGATION_REQUIRED、ROPAGATION_NESTED）的方法来说，声明事务超时才有意义。

2.6、回滚规则

在默认设置下，事务只在出现运行时异常（runtime exception）时回滚，而在出现受检查异常（checked exception）时不回滚（这一行为和EJB中的回滚行为是一致的）。
不过，可以声明在出现特定受检查异常时像运行时异常一样回滚。同样，也可以声明一个事务在出现特定的异常时不回滚，即使特定的异常是运行时异常。