【SSM - Spring篇07】- 事务 - Spring事务管理

╰+攻爆jí腚メ 2022-12-08 15:39 91阅读 0赞

### 文章目录 ###

*   *  1. 事务
     *   *  1.1 事务的特性
         *  1.2 事务隔离级别
         *  1.3 事务的传播特性
         *  1.4 事务的回滚规则
     *  2. Spring事务管理
     *   *  2.1 声明式事务管理
         *   *  2.1.1 基于@Transactional注解的方式
             *  2.1.2 基于XML的方式
         *  2.2 编程式事务管理

## 1. 事务 ##

就是一个完整的执行单位，必须全部执行，任何异常都要回滚，返回

### 1.1 事务的特性 ###

事务具有ACID四个特性：

>   **原子性(Atomicity)**：事务是一个**不可分割的工作单位，事务中的操作要么都发生，要么都不发生**  
>   **一致性(Consistency)**：事务在完成后数据的完整性必须保持一致  
>   **隔离性(Isolation)**：多个用户并发访问数据库时，一个用户的事务不能被其他用户的事务所干扰，多个并发事务之间的数据要相互隔离  
>   **持久性（Durability）**：一个事务一旦被提交，它对数据库中数据的改变应该是永久性的，即使数据库发生故障也不应该对其有任何影响

如果整个事务执行过程中，有任何一个地方出现异常/错误，那么都会进行事务回滚，回滚之后数据的状态将和事务执行之前完全一致。

### 1.2 事务隔离级别 ###

隔离级别是指若干个并发的事务之间的隔离程度。TransactionDefinition 接口中定义有五个表示隔离级别的常量（用于解决并发问题，实际上就是四个值，有一个是默认值常量）：

<table> 
 <thead> 
  <tr> 
   <th align="left">TransactionDefinition 接口事务隔离级别</th> 
   <th align="left">描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">ISOLATION_DEFAULT</td> 
   <td align="left">默认值，表示使用底层数据库的默认隔离级别。对大部分数据库而言，通常这值就是<strong>TransactionDefinition.ISOLATION_READ_COMMITTED</strong></td> 
  </tr> 
  <tr> 
   <td align="left">ISOLATION_READ_UNCOMMITTED</td> 
   <td align="left">该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。该级别<strong>不能防止脏读，不可重复读和幻读</strong>，因此很少使用该隔离级别。</td> 
  </tr> 
  <tr> 
   <td align="left">ISOLATION_READ_COMMITTED</td> 
   <td align="left">该隔离级别表示一个事务只能读取另一个事务已经提交的数据。<strong>可以防止脏读</strong>，是大多数情况下的推荐值。</td> 
  </tr> 
  <tr> 
   <td align="left">ISOLATION_REPEATABLE_READ</td> 
   <td align="left">该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询，并且每次返回的记录都相同。该级别<strong>可以防止脏读和不可重复读</strong>。</td> 
  </tr> 
  <tr> 
   <td align="left">ISOLATION_SERIALIZABLE</td> 
   <td align="left">所有的事务依次逐个执行，事务之间就完全不可能产生干扰。<strong>该级别可以防止脏读、不可重复读以及幻读</strong>。但是这将<strong>严重影响程序的性能</strong>。通常情况下也不会用到该级别。</td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <thead> 
  <tr> 
   <th align="left">隔离级别（√：允许出现 ×：不允许出现）</th> 
   <th>脏读</th> 
   <th>不可重复读</th> 
   <th>幻读</th> 
   <th>第一类丢失更新</th> 
   <th>第二类丢失更新</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">READ_UNCOMMITTED</td> 
   <td>√</td> 
   <td>√</td> 
   <td>√</td> 
   <td>×</td> 
   <td>√</td> 
  </tr> 
  <tr> 
   <td align="left">READ_COMMITTED</td> 
   <td>×</td> 
   <td>√</td> 
   <td>√</td> 
   <td>×</td> 
   <td>√</td> 
  </tr> 
  <tr> 
   <td align="left">REPEATABLE_READ</td> 
   <td>×</td> 
   <td>×</td> 
   <td>√</td> 
   <td>×</td> 
   <td>×</td> 
  </tr> 
  <tr> 
   <td align="left">SERIALIZABLE</td> 
   <td>×</td> 
   <td>×</td> 
   <td>×</td> 
   <td>×</td> 
   <td>×</td> 
  </tr> 
 </tbody> 
</table>

> **事务隔离级别和数据访问的并发性是对立的，事务隔离级别越高并发性就越差**。所以要根据具体的应用来确定合适的事务隔离级别，这个地方没有万能的原则。

事务的并发问题

>   首先要知道，**只有存在并发数据访问时才需要事务**（提交/回滚就结束事务），当多个事务访问同一数据时，可能会存在5类并发问题，包括3 类数据读取问题（ 脏读、不可重复读和幻  
> 读和2类数据更新问题（第1 类丢失更新和第2 类丢失更新）  
> 3类数据读取问题
> 
> > 1）**脏读（Dirty Read）**： 一个事务读到了另一个事务的还没有提交数据. （比如A事务读取B事务尚未提交的数据并在此基础上操作，而B事务执行回滚，那么A 读取到的数据就是脏数据。）（很严重的行为，必须处理，不然可能有很大的影响，比如转账事务）  
> > 2）**不可重复读(Unrepeatable Read)**： 一个事务中多次读到的数据不一致，一个事务读到了另一个事务修改后的数据。（不可重复读，保证数据修改后，不会出现两次一样的数据）  
> > 3） **幻读(虚读Phantom Read)**：一个事务读到了另一个事务insert提交的数据。（比如事务A 重新执行一个查询，返回一系列符合查询条件的行，发现其中插入了被事务B 提交的行）（不可能出现在MySQL中，只会出现在Oracle中）
> 
> 两类丢失更新问题
> 
> > 1）第一类丢失更新：  
> >   事务A撤销时， 把已经提交的事务B的更新数据覆盖了（比如 取款事务A开启事务查询余额1000元，转账事务B开启事务转账100给A，A取出100，提交事务之后，再查询余额还是1000元）  
> > 2）事务A覆盖事务 已经提交的数据，造成事务B 所做的操作丢失（比如：取款事务A和转账B先后开启事务，先后查询余额都是1000元，取款事务A取出100，余额变成900，提交事务，但是此时转账事务B存入100，将余额修改为1100元，提交事务，然后再查询帐户余额就是1100，取款事务A的操作丢失）

### 1.3 事务的传播特性 ###

事务传播特性：如果在开始当前事务之前，一个事务上下文已经存在，此时有若干选项可以指定一个事务性方法的执行行为。  
  TransactionDefinition中定义中这些表示传播行为的常量

<table> 
 <thead> 
  <tr> 
   <th align="left">TransactionDefinition事务传播行为常量</th> 
   <th align="left">描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">PROPAGATION_REQUIRED</td> 
   <td align="left">默认值。如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务</td> 
  </tr> 
  <tr> 
   <td align="left">PROPAGATION_REQUIRES_NEW</td> 
   <td align="left">创建一个新的事务，如果当前存在事务，则把当前事务挂起</td> 
  </tr> 
  <tr> 
   <td align="left">PROPAGATION_SUPPORTS</td> 
   <td align="left">如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行</td> 
  </tr> 
  <tr> 
   <td align="left">PROPAGATION_NOT_SUPPORTED</td> 
   <td align="left">以非事务方式运行，如果当前存在事务，则把当前事务挂起。</td> 
  </tr> 
  <tr> 
   <td align="left">PROPAGATION_NEVER</td> 
   <td align="left">以非事务方式运行，如果当前存在事务，则抛出异常。</td> 
  </tr> 
  <tr> 
   <td align="left">PROPAGATION_MANDATORY</td> 
   <td align="left">如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。</td> 
  </tr> 
  <tr> 
   <td align="left">PROPAGATION_NESTED</td> 
   <td align="left">如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则该取值等价于TransactionDefinition.PROPAGATION_REQUIRED。</td> 
  </tr> 
 </tbody> 
</table>

### 1.4 事务的回滚规则 ###

默认配置下，spring只有在抛出的异常为运行时unchecked异常时才回滚该事务，也就是抛出的异常为RuntimeException的子类(Errors也会导致事务回滚)，而**抛出checked异常则不会导致事务回滚**。可以明确的配置在抛出哪些异常时回滚事务，包括checked异常。也可以明确定义那些异常抛出时不回滚事务。还可以编程性的通过setRollbackOnly()方法来指示一个事务必须回滚，在调用完setRollbackOnly()后你所能执行的唯一操作就是回滚。

## 2. Spring事务管理 ##

Spring事务管理分为**编程式事务管理**和**声明式事务管理**

### 2.1 声明式事务管理 ###

声明式事务是建立在AOP之上的。其本质是**对方法前后进行拦截**，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。  
  声明式事务管理最大的优点是不需要通过编程的方式管理事务，因而不需要在业务逻辑代码中掺杂事务处理的代码，只需相关的事务规则声明，便可以将事务规则应用到业务逻辑中

//如果不想某个异常进行事务处理
    @Transactional(rollbackFor=RuntimeException.class)//不对RuntimeException回滚生效
    @Transactional(rollbackFor=Exception.class)// 不对Exception回滚生效

Spring的声明式事务管理可以通过两种方式来实现:

1.  **基于@Transactional注解的方式**。
2.  **基于XML的方式**

#### 2.1.1 基于@Transactional注解的方式 ####

**直接在Service层的方法上面加上@Transactional注解**  
在applicationContext.xml中要配置事务管理器

<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
            <property name="dataSource" ref="dataSource"/>
        </bean>
    
        
        <tx:annotation-driven transaction-manager="transactionManager"/>

案例实现：[https://github.com/strive-xgf/SSM/commit/d855985d82db5d969a9e9820fe0686f8ce9341bc][https_github.com_strive-xgf_SSM_commit_d855985d82db5d969a9e9820fe0686f8ce9341bc]

#### 2.1.2 基于XML的方式 ####

>  *  基于XML方式的声明式事务管理是通过在配置文件中配置事务规则的相关声明来实现的。Spring框架提供了**tx命名空间来配置事务**。
>  *  tx:advice元素来配置**事务的通知**。配置tx:advice元素时，一般需要指定id和transaction-manager属性，其中id属性是配置文件中的唯一标识，transaction-manager属性指定事务管理器。
>  *  tx:attributes子元素，该子元素可配置多个tx:method子元素指定执行事务的细节。
>  *  当tx:advice元素配置了事务的增强处理后，就可以通过编写AOP配置，让Spring自动对目标对象生成代理。

需要在applicationContext.xml中配置事务和通知

案例实现：[https://github.com/strive-xgf/SSM/commit/61cae51d9a69975ab2caa75249c84d484accff83][https_github.com_strive-xgf_SSM_commit_61cae51d9a69975ab2caa75249c84d484accff83]

### 2.2 编程式事务管理 ###

基于底层API的编程式事务管理，就是根据PlatformTransactionManager、TransactionDefinition 和 TransactionStatus 三个核心接口，通过编程的方式来进行事务处理。spring推荐使用**TransactionTemplate**。  
  在代码中**显式调用** **beginTransaction()**、**commit()**、\*\*rollback() \*\* 等事务处理相关的方法，这就是编程式事务管理。

>   TransactionTemplate的execute()方法有一个TransactionCallback接口类型的参数，该接口中定义了一个doInTransaction()方法，通常以匿名内部类的方式实现TransactionCallback 接口，并在其doInTransaction()方法中书写业务逻辑代码。这里可以使用默认的事务提交和回滚规则，在业务代码中不需要显式调用任何事务处理的API。doInTransaction()方法有一个TransactionStatus类型的参数，可以在方法的任何位置调用该参数的setRollbackOnly()方法将事务标识为回滚，以执行事务回滚。  
>   根据默认规则，如果在执行回调方法的过程中抛出了未检查异常，或者显式调用了setRollbackOnly()方法，则回滚事务；如果事务执行完成或者抛出了checked类型的异常，则提交事务。

案例实现：[https://github.com/strive-xgf/SSM/commit/fe39a52b5d2f6c692db7ed0a373c6e327cb8a267][https_github.com_strive-xgf_SSM_commit_fe39a52b5d2f6c692db7ed0a373c6e327cb8a267]

[https_github.com_strive-xgf_SSM_commit_d855985d82db5d969a9e9820fe0686f8ce9341bc]: https://github.com/strive-xgf/SSM/commit/d855985d82db5d969a9e9820fe0686f8ce9341bc
[https_github.com_strive-xgf_SSM_commit_61cae51d9a69975ab2caa75249c84d484accff83]: https://github.com/strive-xgf/SSM/commit/61cae51d9a69975ab2caa75249c84d484accff83
[https_github.com_strive-xgf_SSM_commit_fe39a52b5d2f6c692db7ed0a373c6e327cb8a267]: https://github.com/strive-xgf/SSM/commit/fe39a52b5d2f6c692db7ed0a373c6e327cb8a267