> 文章列表 > Spring 事务管理详解及使用

Spring 事务管理详解及使用

事务,这个看似高冷的概念,其实就像一道防止数据库出车祸的“防护栏”。在Java开发中,事务管理的“四条铁律”(ACID)就像交通规则,确保数据的一致性和完整性。

问题一:为什么说数据库的“酸”很重要?

酸性数据库(ACID)就像食品安全,保证了数据的“原子性”(要么全做,要么全不做)、“一致性”(数据永远处于合法状态)、“隔离性”(事务之间互不干扰)、“持久性”(提交即保存)。就像你点外卖,要么收到完整的餐品,要么钱不会被扣,这就是事务的原子性。

问题二:为什么事务不能太“任性”?

事务的隔离级别就像数据的“保护伞”,解决“脏读”、“不可重复读”、“幻读”问题。比如在 MySQL 中,默认使用“可重复读”隔离级别,确保你在同一个事务中看到的数据是一致的。就像一个人在ATM机上查了两次余额,结果金额不一样,这显然是个问题。

问题三:为什么事务管理器是事务的“大管家”?

Spring 中的 PlatformTransactionManager 接口就像事务的总指挥,负责事务的提交、回滚和状态管理。就像餐厅的经理,协调各个服务人员(事务)的工作流程。当你用 @Transactional 注解时,实际上是在请这位“大管家”来管理你的事务。

问题四:事务传播行为为什么像是服务员之间的“传菜单”?

事务的传播行为定义了不同事务之间的协作方式,比如“传播需要”(PROPAGATION_REQUIRED)就像服务员之间接力传递订单,确保订单处理在一个事务中完成。而“需要新事务”(PROPAGATION_REQUIRES_NEW)就像给一个特别复杂的订单单独安排服务员处理,保证不干扰其他工作。

总之,事务管理就像一场精心策划的“数据保卫战”,确保数据在多用户并发操作下的绝对安全。

Spring 事务管理详解及使用

在这里插入图片描述

✅作者简介:2022年博客新星 第八。热爱国学的Java后端开发者,修心和技术同步精进。
🍎个人主页:Java Fans的博客
🍊个人信条:不迁怒,不贰过。小知识,大智慧。
💞当前专栏:SSM 框架从入门到精通
✨特色专栏:国学周更-心性养成之路
🥭本文内容:一文吃透 Spring 中的IOC和DI

文章目录

  • Spring 事务管理接口
    • 1、事务管理器接口 PlatformTransactionManager
    • 2、事务定义接口 TransactionDefinition
  • Spring 事务管理的实现方法
    • 1、没有事务管理的情况分析
    • 2、通过配置 XML 实现事务管理
    • 3、利用注解实现事务管理
    • 4、在业务层实现事务管理

Spring 事务管理详解及使用

  事务(Transaction)是访问数据库的一个操作序列,这些操作要么都做,要么都不做,是一个不可分割的工作单元。通过事务,数据库能将逻辑相关的一组操作绑定在一起,以便保持数据的完整性。

事务有4个重要特性,简称 ACID

  • A:Automicity原子性,即事务中的所有操作要么全部执行,要么全部不执行。
  • C:Consistency一致性,事务执行的结果必须是使数据库从一个一致状态变到另一个一致状态。
  • I:Isolation隔离性,即一个事务的执行不能被另一个事务影响。
  • D:Durabillity持久性,即事务提交后将被永久保存。

  在Java EE开发中,事务原本属于 Dao 层中的范畴,但一般情况下需要将事务提升到业务层(Service层),以便能够使用事务的特性来管理具体的业务。

Spring 事务管理接口

  Spring 的事务管理,主要用到两个事务相关的接口。

1、事务管理器接口 PlatformTransactionManager

  事务管理器接口 PlatformTransactionManager 主要用于完成事务的提交、回滚,及获取事务的状态信息。PlatformTransactionManager 接口有两个常用的实现类:

  • DataSourceTransactionManager实现类:使用JDBC或MyBatis进行数据持久化时使用。
  • HibernateTransactionManager实现类:使用Hibernate进行数据持久化时使用。

  关于Spring的事务提交与回滚方式,默认是:发生运行时异常时回滚,发生受检查异常时提交, 也就是说程序抛出runtime异常的时候才会进行回滚,其他异常不回滚。

2、事务定义接口 TransactionDefinition

  事务定义接口 TransactionDefinition 中定义了事务描述相关的三类常量:事务隔离级别常量事务传播行为常量事务默认超时时限常量,及对它们的操作。

【1】事务隔离级别常量

  在应用程序中,多个事务并发运行,操作相同的数据,可能会引起脏读,不可重复读,幻读等问题 。

  • 脏读(Dirty reads):第一个事务访问并改写了数据,尚未提交事务,这时第二个事务进来了,读取了刚刚改写的数据,如果这时第一个事务回滚了,这样第二个事务读取到的数据就是无效的“脏数据”。
  • 不可重复读(Nonrepeatable read):第一个事务在其生命周期内多次查询同一个数据,在两次查询之间,第二个事务访问并改写了该数据,导致第一个事务两次查询同一个数据得到的结果不一样。
  • 幻读(Phantom read)——幻读与不可重复读类似。它发生在第一个事务在生命周期进行了两次按同一查询条件查询数据,第一次按该查询条件读取了几行数据,这时第二个事务进来了,插入或删除了一些数据时,然后第一个事务再次按同一条件查询,发现多了一些原本不存在的记录或者原有的记录不见了。

  为了解决并发问题,TransactionDefinition 接口定义了5个事务隔离常量如下:

  • DEFAULT:采用数据库 默认 的事务隔离级别。不同数据库不一样,MySql的默认为 REPEATABLE_READ(可重复读);Oracle默认为READ_COMMITTED(读已提交)。
  • READ_UNCOMMITTED读未提交。允许另外一个事务读取到当前事务未提交的数据,隔离级别最低,未解决任何并发问题,会产生脏读,不可重复读和幻像读。
  • READ_COMMITTED读已提交,被一个事务修改的数据提交后才能被另外一个事务读取,另外一个事务不能读取该事务未提交的数据。解决脏读,但还存在不可重复读与幻读。
  • REPEATABLE_READ可重复读。解决了脏读、不可重复读,但还存在幻读。
  • SERIALIZABLE串行化。按时间顺序一一执行多个事务,不存在并发问题,最可靠,但性能与效率最低。

【2】事务传播行为常量

  事务传播行为是指处于不同事务中的方法在相互调用时,执行期间事务的维护情况。例如,当一个事务方法B调用另一个事务方法A时,应当明确规定事务如何传播,比方可以规定A方法继续在B方法的现有事务中运行,也可以规定A方法开启一个新事务,在新事务中运行,现有事务先挂起,等A方法的新事务执行完毕后再恢复。TransactionDefinition 接口一共定义了 七种 传播行为常量说明如下。

  • PROPAGATION_ REQUIRED:指定的方法必须在事务内执行。若当前存在事务,就加入到当前事务中;若当前没有事务,则创建一个新事务。这种传播行为是最常见的选择,也是 Spring 默认的事务传播行为。如该传播行为加在actionB ()方法上,该方法将被actionA ()调用,若actionA ()方法在执行时就是在事务内的,则actionB ()方法的执行也加入到该事务内执行。若actionA ()方法没有在事务内执行,则actionB ()方法会创建一个事务,并在其中执行。
  • PROPAGATION_ SUPPORTS:指定的方法支持当前事务,但若当前没有事务,也可以以非事务方式执行。
  • PROPAGATION_ MANDATORY:指定的方法必须在当前事务内执行,若当前没有事务,则直接抛出异常。
  • PROPAGATION_ REQUIRES_NEW:总是新建一个事务,若当前存在事务,就将当前事务挂起,直到新事务执行完毕。
  • PROPAGATION_ NOT_SUPPORTED:指定的方法不能在事务环境中执行,若当前存在事务,就将当前事务挂起。
  • PROPAGATION_ NEVER:指定的方法不能在事务环境下执行,若当前存在事务,就直接抛出异常。
  • PROPAGATION_ NESTED