Spring事务

Spring

Spring JAVA

发布日期: 2020-01-02

文章字数: 2k

基本概念

事务（Transaction)是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元（Unit)。

事务特性（ACID）

事务有四个特性：ACID

原子性（Atomicity）:事务的原子性是指事务必须是一个原子的操作序列单元,要么全部成功执行，要么全部不执行
一致性（Consistency）：事务的一致性是指事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行之前和执行之后，数据库都必须处于一致性状态。
隔离性（Isolation）：事务的隔离性是指在并发环境中，并发的事务是相互隔离的，一个事务的执行不能被其他事务干扰。隔离级别需要数据库的支持，比如

MYSQL

隔离级别脏读不可重复读幻读

Read Uncommitted √ √ √

Read Committed × √ √

Repeatable Read × × √

Serializable × × ×
Oracle就只支持Read Committed和Serializable

隔离级别	脏读	不可重复读	幻读
Read Uncommitted	√	√	√
Read Committed	×	√	√
Repeatable Read	×	×	√
Serializable	×	×	×

持久性（Durability）：事务的持久性也被称为永久性，是指一个事务一旦提交，它对数据库中对应数据的状态变更就应该是永久性的。

事务的传播

传播行为	含义
PROPAGATION_REQUIRED	表示当前方法必须在一个具有事务的上下文中运行，如有客户端有事务在进行，那么被调用端将在该事务中运行，否则的话重新开启一个事务。（如果被调用端发生异常，那么调用端和被调用端事务都将回滚）
PROPAGATION_SUPPORTS	表示当前方法不必需要具有一个事务上下文，但是如果有一个事务的话，它也可以在这个事务中运行
PROPAGATION_MANDATORY	表示当前方法必须在一个事务中运行，如果没有事务，将抛出异常
PROPAGATION_NESTED	表示如果当前方法正有一个事务在运行中，则该方法应该运行在一个嵌套事务中，被嵌套的事务可以独立于被封装的事务中进行提交或者回滚。如果封装事务存在，并且外层事务抛出异常回滚，那么内层事务必须回滚，反之，内层事务并不影响外层事务。如果封装事务不存在，则同PROPAGATION_REQUIRED的一样
PROPAGATION_NEVER	表示当方法务不应该在一个事务中运行，如果存在一个事务，则抛出异常
PROPAGATION_REQUIRES_NEW	表示当前方法必须运行在它自己的事务中。一个新的事务将启动，而且如果有一个现有的事务在运行的话，则这个方法将在运行期被挂起，直到新的事务提交或者回滚才恢复执行
PROPAGATION_NOT_SUPPORTED	表示该方法不应该在一个事务中运行。如果有一个事务正在运行，他将在运行期被挂起，直到这个事务提交或者回滚才恢复执行

Spring的事务管理是通过线程相关的ThreadLocal来保存数据访问基础设施的（Connection对象），再结合IoC和AOP实现高级声明式事务的功能，所以Spring的事务天然的和线程有着千丝万缕的关系。
Spring通过ThreadLocal可以将大部分Bean无状态化（线程安全的）所以Spring中单实例Bean对线程安全问题拥有一种天然的免疫力。
所以Spring中DAO和Service都以单实例的方式存在，Spring将有状态的变量（Connection）本地线程化，达到另一个层面上的线程无关，从而实现线程无关。
总结：在相同的线程中进行相互嵌套调用的事务方法工作于相同的事务中，不同的线程中，则各自独立工作与独立的事务中。

Spring 事务管理

事务管理接口

编程式事务

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

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

通过API自己控制事务:

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

声明式事务

声明式事务管理方法允许开发者配置的帮助下来管理事务，而不需要依赖底层API进行硬编码。开发者可以只使用注解或基于配置的 XML 来管理事务。

@Transactional
public void test() {
     // 事务操作  
}

*使用事务还需要一些配置内容。

声明式事务的优点

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

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

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

声明式事务的粒度问题

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

如果想要给一部分代码块增加事务的话，那就需要把这个部分代码块单独独立出来作为一个方法,因为声明式事务是通过注解的，有些时候还可以通过配置实现，这就会导致一个问题，那就是这个事务有可能被开发者忽略:

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

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

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

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

有些时候，即使没有在事务中进行远程操作，但是有些人还是可能会不经意的进行一些内存操作，如运算。或者如果遇到分库分表的情况，有可能不经意间进行跨库操作。
但是如果是编程式事务的话，业务代码中就会清清楚楚看到什么地方开启事务，什么地方提交，什么时候回滚。这样有人改这段代码的时候，就会强制他考虑要加的代码是否应该方法事务内。