Spring事务处理

发表于 | 分类于

什么是Spring事务

事务（Transaction）是并发控制的单位，是用户定义的一个操作序列。这些操作要么都做，要么都不做，是一个不可分割的工作单位。
数据库向用户提供保存当前程序状态的方法，叫事务提交（commit）；当事务执行过程中，使数据库忽略当前的状态并回到前面保存的状态的方法叫事务回滚（rollback）

事务特性（ACID）

原子性（atomicity）： 将事务中所做的操作捆绑成一个原子单元，即对于事务所进行的数据修改等操作，要么全部执行，要么全部不执行。
一致性（Consistency)： 事务在完成时，必须使所有的数据都保持一致状态，而且在相关数据中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时，所有的内部数据结构都应该是正确的。
隔离性（Isolation）： 由并发事务所做的修改必须与任何其他事务所做的修改相隔离。事务查看数据时数据所处的状态，要么是被另一并发事务修改之前的状态，要么是被另一并发事务修改之后的状态，即事务不会查看由另一个并发事务正在修改的数据。这种隔离方式也叫可串行性。
持久性（Durability）： 事务完成之后，它对系统的影响是永久的，即使出现系统故障也是如此。

事务隔离（Isolation Level）

事务隔离意味着对于某个运行着的事务来说，类似于系统中只有一个事物，其他并发事务都不存在一样
大部分情况下很少使用安全隔离的事务，但是不完全隔离的事务会带来如下问题：
更新丢失（Lost Update）： 两个事务都企图去更新一行数据，导致事务抛出异常退出。
脏数据（Dirty Read）： 如果第二个应用程序使用了第一个应用程序修改过的数据，而这个数据处于未提交状态，这时就会发生脏读。第一个应用程序随后可能会请求回滚被修改的数据，从而导致第二个事务使用的数据被损坏，即所谓的“变脏”。
不可重读（Unrepeatable Read）： 一个事务两次读同一行数据，可是这两次读到的数据不一样，就叫不可重读。如果一个事务在提交数据之前，另一个事务可以修改和删除这些数据，就会发生不可重读。
幻读（Phantom Read）： 一个事务执行了两次查询，发现第二次查询结果比第一次查询多出了一行，这可能是因为另一个事务在这两次查询之间插入了新行。

那么为了避免此类问题，提供出了以下隔离级别来防范:

读操作未提交（Read Uncommitted）： 读取未提交的数据是允许的。说明一个事务在提交前，其变化对于其他事务来说是可见的。这样脏读、不可重读和幻读都是允许的。当一个事务已经写入一行数据但未提交，其他事务都不能再写入此行数据；但是，任何事务都可以读任何数据。这个隔离级别使用排写锁实现。
读操作已提交（Read Committed）： 读取未提交的数据是不允许的，它使用临时的共读锁和排写锁实现。这种隔离级别不允许脏读，但不可重读和幻读是允许的。
可重读（Repeatable Read）： 说明事务保证能够再次读取相同的数据而不会失败。此隔离级别不允许脏读和不可重读，但幻读会出现。
可串行化（Serializable）： 提供最严格的事务隔离。这个隔离级别不允许事务并行执行，只允许串行执行。这样，脏读、不可重读或幻读都可发生。

事务隔离与隔离级别的关系：

隔离级别 脏读（Dirty Read） 不可重读（Unrepeatable read） 幻读（Phantom Read）
读操作未提交（Read Uncommitted） 可能 可能 可能
读操作已提交（Read Committed） 不可能 可能 可能
可重读（Repeatable Read） 不可能 不可能 可能
可串行化（Serializable） 不可能 不可能 不可能

事务的传播（Propagation）

事务传播行为类型 说明
PROPAGATION_REQUIRED 如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。这是 最常见的选择。
PROPAGATION_SUPPORTS 支持当前事务，如果当前没有事务，就以非事务方式执行。
PROPAGATION_MANDATORY 使用当前的事务，如果当前没有事务，就抛出异常。
PROPAGATION_REQUIRES_NEW 新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_NOT_SUPPORTED 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
PROPAGATION_NEVER 以非事务方式执行，如果当前存在事务，则抛出异常。
PROPAGATION_NESTED 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与 PROPAGATION_REQUIRED 类似的操作。

readOnly 事务属性中的readOnly标志表示对应的事务应该被最优化为只读事务。这是一个最优化提示 。在一些情况下，一些事务策略能够起到显著的最优化效果，例如在使用Object/Relational映射工具 （如：Hibernate或TopLink）时避免dirty checking（试图“刷新”）。
Timeout 在事务属性中还有定义“timeout”值的选项，指定事务超时为几秒。在JTA中，这将被简单地传递到J2EE服务器的事务协调程序，并据此得到相应的解释。

事务的嵌套

  1. PROPAGATION_REQUIRED 加入当前正要执行的事务不在另外一个事务里，那么就起一个新的事务。即，如果存在主事务，则将此事务合并到主事务中，提交和回滚与主事务依赖，不存在主事务则会自起事务。
  2. PROPAGATION_SUPPORTS 如果当前在事务中，即以事务的形式运行，如果当前不再一个事务中，那么就以非事务的形式运行。
  3. PROPAGATION_MANDATORY 必须在一个事务中运行。也就是说，他只能被一个父事务调用。否则，他就要抛出异常
  4. PROPAGATION_REQUIRES_NEW 在主事务中，创建一个新的事务（子事务）并挂起主事务，执行完子事务后，主事务继续执行，但是，如果子事务已经提交，当主事务失败回滚时，子事务是不回滚的
  5. PROPAGATION_NOT_SUPPORTED 当前不支持事务，当存在事务中时，会将主事务挂起，当以非事务状态执行完后在继续执行主事务
  6. PROPAGATION_NEVER 不能在事务中运行，否则抛异常。
  7. PROPAGATION_NESTED 它与PROPAGATION_REQUIRES_NEW的区别是，不另起事务，与主事务相依，而且需要等主事务提交时才会提交，主事务回滚它也回滚。

Spring事务处理

Spring配置文件中关于事务配置总是由三个组成部分，分别是DataSource、TransactionManager和代理机制这三部分，无论哪种配置方式，一般变化的只是代理机制这部分。
Spring处理事务主要有五种方法：

  1. 每个bin都有一个代理
  2. 所有bin共享一个代理基类
  3. 使用拦截器
  4. 使用tx标签配置的拦截器
  5. 全注解
    此处只简单介绍全注解：
    在配置好数据库配置后，需要 定义事务管理器 
    1
    2
    3
    4
    <bean id="transactionManager"
            class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
        <property name="dataSource" ref="datasource"/>
      </bean>
    然后在需要事务的方法上添加 @Transactional 注解。

@Transactional

@Transactional的含义

关键点之一是要考虑两个独立的概念，它们都有各自的范围和生命周期：

  • persistence context(持久化上下文)
  • database transaction（事务）
    @Transactional本身定义了单个事务的范围。这个事务在persistence context的范围内。
    JPA中的持久化上下文是EntityManager，内部实现使用了Hibernate Session（使用Hibernate作为持久化provider）
    持久化上下文仅仅是一个同步对象，它记录了有限集合的Java对象的状态，并且保证这些对象的变化最终持久化到数据库。
    这是与单个事务非常不同的概念。一个Entity Manager可以跨越多个事务使用，而且的确是这样使用的。

    EntityManager和Transaction之间的关系:

    JPA Entity Manager最常用的方式是“Entity Manager per application transaction”(每个事务都有自己的实体管理器)模式。entity manager注入的常用方法是： 
    1
    2
    @PersistenceContext
    private EntityManager em;
    这里默认为“Entity Manager per transaction”模式。这种模式下如果在@Transactional方法内部使用该Entity Manager，那么该方法将在单一事务中运行。

@PersistenceContext的工作原理

随之而来的问题就是@PersistenceContext如何仅在容器启动时注入entity manager，假定entity manager生命周期很短暂，而且每次请求需要多个entity manager。
答案是它不能：EntityManager是一个接口，注入到spring bean中的不是entity manager本身，而是在运行时代理具体entity manager的context aware proxy（上下文感知代理）。
通常用于代理的具体类为SharedEntityManagerInvocationHandler，借助调试器可以确认这一点。

@Transactional如何工作的

实现了EntityManager接口的持久化上下文代理并不是声明式事务管理的唯一部分，事实上包含三个组成部分：

  • EntityManager Proxy本身
  • 事务的切面
  • 事务管理器
    事务的切面：
    事务的切面是一个“around（环绕）”切面，在注解的业务方法前后都可以被调用。实现切面的具体类是TransactionInterceptor。
    事务的切面有两个主要职责：
  • 在’before’时，切面提供一个调用点，来决定被调用业务方法应该在正在进行事务的范围内运行，还是开始一个新的独立事务。
  • 在’after’时，切面需要确定事务被提交，回滚或者继续运行。
  • 在’before’时，事务切面自身不包含任何决策逻辑，是否开始新事务的决策委派给事务管理器完成。
事务管理器：

事务管理器需要解决下面两个问题：

  • 新的Entity Manager是否应该被创建？
  • 是否应该开始新的事务？

这些需要事务切面’before’逻辑被调用时决定。事务管理器的决策基于以下两点：

  • 事务是否正在进行
  • 事务方法的propagation属性（比如REQUIRES_NEW总要开始新事务）

如果事务管理器确定要创建新事务，那么将：

  • 创建一个新的entity manager
  • entity manager绑定到当前线程
  • 从数据库连接池中获取连接
  • 将连接绑定到当前线程

摘自：https://www.cnblogs.com/mxmbk/p/5341258.html