Spring 的事务管理

在一个实际项目中事务都是由业务层进行管理的，因为业务逻辑上的一组操作才是实际意义上的事务。

_Spring的事务管理.png

数据库系统中有事务，Dao 层中也有事务，业务层中也有事务。三者范围如图所示

数据库的事务

由具体的数据库管理系统进行管理

_数据库的事务.png

事务的ACID特性

原子性：事务是一个不可分割的操作的集合
一致性：当事务完成时，必须使所有的数据都保持一直状态
隔离性：事务和事务之间不能互相干扰。这里的事务和线程就类似了，线程和线程之间也不应该互相干扰PROPAGATION_REQUIRED
持久性：事务一旦提交，它在数据库中的改变就是永久性的

不考虑事务隔离性带来的问题

脏读：一个事务读到了另一个事务未提交的数据
不可重复读：一个事务读到了另一个事务已经提交的** update **的数据，导致在同一个事务中的多次查询结果不一致。也就是第一次读到数据 A ，第二次读到另一个事务更改后的数据 B ，导致两次读到的数据不同。
虚读：一个事务读到了另一个事务已经** insert **的数据，导致在同一个事务中的多次查询结果不一致。也就是第一次读到数据 A ，第二次读到另一个事务插入后的新数据 B ，导致两次读到的数据不同。

事务的隔离级别

为了避免造成上述的几种并发问题，在标准 SQL 规范中，定义了 4 个事务隔离级别，不同的隔离级别对事务的处理不同。

读未提交( Read Uncommitted ,1 级)：什么读问题解决不了
已提交读( Read committed ，2 级)：可以解决脏读问题，必须在事务提交后，才可读到数据
可重复读( Repeatable Read，4 级)：解决脏读和不可重复读，也就是在另一个事务进行update操作的时候，不能读数据
序列化/串行化( Serializable，8 级)：完全符合事务的 ACID 的隔离级别，但是效率很低。

事务的隔离级别是由数据库提供的保护机制，隔离级别越高，安全性就越高，但是效率就越低。

事务管理的API

Spring 中进行事务管理主要有三个接口

PlatformTransactionManager，平台事务管理器，是Spring用于管理事务的真正的对象。该接口有两个实现类如下
- DataSourceTransactionManager，底层使用 JDBC 管理事务
- HibernateTransactionManager，底层使用 Hibernate 管理事务
TransactionDefinition，事务定义信息，用于定义事务的相关的信息，比如，隔离级别、超时信息、传播行为、是否只读等
TransactionStatus，事务的状态，用于记录在事务管理过程中，事务的状态的对象。

事务管理的 API 的关系：Spring 进行事务管理的时候，首先平台事务管理器根据事务定义信息进行事务的管理，在事务管理过程中，产生各种状态，将这些状态的信息记录到事务状态的对象中。

事务的传播行为

业务层中的方法是一个事务，但是很多时候，业务层中的方法也需要互相调用，这就带来了新的事务问题。

如何保证这种业务层方法互相调用产生的新的事务呢？这就是事务的传播行为所需要关心的问题。

Spring 中提供了七种事务的传播行为来解决此问题：

保证多个操作在同一个事务中
- PROPAGATION_REQUIRED(90%情况下都用这个)：默认值，如果A中有事务，使用A中的事务(包起来)，如果A没有，创建一个新的事务，将操作包含进来
- PROPAGATION_SUPPORTS：支持事务，如果A中有事务，使用A中的事务(包起来)。如果A没有事务，不使用事务。
- PROPAGATION_MANDATORY：如果A中有事务，使用A中的事务(包起来)。如果A没有事务，抛出异常。
保证多个操作不在同一个事务中
- PROPAGATION_REQUIRES_NEW：如果A中有事务，将A的事务挂起（暂停），创建新事务，只包含自身操作。如果A中没有事务，创建一个新事务，包含自身操作。
- PROPAGATION_NOT_SUPPORTED：如果A中有事务，将A的事务挂起。不使用事务管理。
- PROPAGATION_NEVER：如果A中有事务，报异常。
嵌套式事务
- PROPAGATION_NESTED：嵌套事务，如果A中有事务，按照A的事务执行，执行完成后，设置一个保存点，执行B中的操作，如果没有异常，执行通过，如果有异常，可以选择回滚到最初始位置，也可以回滚到保存点。

确实有这么多种类型的事务传播行为，但是 Spring 中默认采用的是PROPAGATION_REQUIRED类型，总之它能实现的功能就是，即使业务层中的某个方法使用了其他的方法，也能够保证着不同的方法之间是一次原子操作。也就是用一个事务把这次操作涉及到的所有方法都当成是一个方法、一个事务看待。

声明式事务

Spring 框架如何在我们编写的代码的基础上添加事务控制的代码呢？更准确的说是在业务层的方法之前开启事务，在方法之后提交事务，并捕获可能发生异常，随时准备进行回滚操作呢？

这不就是典型的 AOP 问题吗？直接在业务层的方法之前添加前置通知，之后添加后置通知不就是了吗？Spring 的事务管理实现的底层机制就是 AOP 。如图所示

_Spring事务实现机制.png

Spring 框架中对事务的封装很完善，在实际配置中，如果没有特殊要求的话，可以配置一个完全通用的模板，保证业务层所有操作都是一个事务，非常的方便，配置也很简单。有以下几个步骤即可

XML 配置

第一步，配置数据源

<!-- 配置C3P0连接池-->
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource">
    <property name="driverClass" value="${jdbc.driverClass}"/>
    <property name="jdbcUrl" value="${jdbc.url}"/>
    <property name="user" value="${jdbc.username}"/>
    <property name="password" value="${jdbc.password}"/>
</bean>

第二步，配置事务管理器实现类

<!-- 配置事务管理器 -->
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="dataSource"/>
</bean>

第三步，配置事务的规则，这里表示所有方法都采用默认的事务传播管理机制，即保证所有操作都是事务安全的

<!-- 配置事务的增强 -->
<tx:advice id="txAdvice" transaction-manager="transactionManager">
    <tx:attributes>
        <!-- 事务管理的规则 -->
        <tx:method name="*" propagation="REQUIRED" read-only="false"/>
    </tx:attributes>
</tx:advice>

第四步，AOP 的配置，指定切入点和事务管理机制

<!-- aop的配置 -->
<aop:config>
    <aop:pointcut expression="execution(* com.itheima.tx.demo2.AccountServiceImpl.*(..))" id="pointcut1"/>
    <aop:advisor advice-ref="txAdvice" pointcut-ref="pointcut1"/>
</aop:config>

注解的配置