Spring的事务管理相关内容-CSDN博客

本文链接：https://blog.csdn.net/sinat_30955745/article/details/106298338

注意，Spring的事务管理功能是通过AOP机制实现的。也就是还是基于动态代理实现的。

很多人就会疑问了，为什么我一个数据查询操作还要启用事务支持呢？

对于只有读取数据查询的事务，可以指定事务类型为 readonly，即只读事务。只读事务不涉及数据的修改，数据库会提供一些优化手段，适合用在有多条数据库查询操作的方法中。
很多人就会疑问了，为什么我一个数据查询操作还要启用事务支持呢？
如果你一次执行单条查询语句，则没有必要启用事务支持，数据库默认支持 SQL 执行期间的读一致性；
如果你一次执行多条查询语句，例如统计查询，报表查询，在这种场景下，多条查询 SQL 必须保证整体的读一致性，否则，在前条 SQL 查询之后，后条 SQL 查询之前，数据被其他用户改变，则该次整体的统计查询将会出现读数据不一致的状态，此时，应该启用事务支持。

自调用问题

若同一类中的其他没有 @Transactional 注解的方法内部调用有 @Transactional 注解的方法，有@Transactional 注解的方法的事务会失效。
这是由于Spring AOP代理的原因造成的，因为只有当 @Transactional 注解的方法在类以外被调用的时候，Spring 事务管理才生效。
解决办法就是避免同一类中自调用或者使用 AspectJ 取代 Spring AOP 代理。

事务管理失效的情况

数据库引擎不支持事务
没有被 Spring 管理（没加@service注解）
方法不是 public 的
自身调用问题
数据源没有配置事务管理器
不支持事务（propagation设置相关）
异常被吃了
异常类型错误

事务简介

• 事务管理是企业级应用程序开发中必不可少的技术 , 用来确保数据的完整性和一致性 .

• 事务就是一系列的动作 , 它们被当做一个单独的工作单元 . 这些动作要么全部完成 , 要么全部不起作用

• 事务的四个关键属性 ( ACID )

– 原子性 (atomicity): 事务是一个原子操作 , 由一系列动作组成 . 事务的原子性确保动作要么全部完成要么完全不起作用 .

– 一致性 (consistency): 一旦所有事务动作完成 , 事务就被提交 . 数据和资源就处于一种满足业务规则的一致性状态中 .

– 隔离性 (isolation): 可能有许多事务会同时处理相同的数据 , 因此每个事物都应该与其他事务隔离开来 , 防止数据损坏 .

– 持久性 (durability): 一旦事务完成 , 无论发生什么系统错误 , 它的结果都不应该受到影响 . 通常情况下 , 事务的结果被写到持久化存储器中 .

事务管理的问题

• 问题 :

– 必须为不同的方法重写类似的样板代码

– 这段代码是特定于 JDBC 的 , 一旦选择类其它数据库存取技术 , 代码需要作出相应的修改

例子：

Spring 中的事务管理

• 作为企业级应用程序框架 , Spring 在不同的事务管理 API 之上定义了一个抽象层 . 而应用程序开发人员不必了解底层的事务管理 API, 就可以使用 Spring 的事务管理机制 .

• Spring 既支持编程式事务管理 , 也支持声明式的事务管理 .

• 编程式事务管理 : 将事务管理代码嵌入到业务方法中来控制事务的提交和回滚 . 在编程式管理事务时 , 必须在每个事务操作中包含额外的事务管理代码 .

• 声明式事务管理 : 大多数情况下比编程式事务管理更好用 . 它 将事务管理代码从业务方法中分离出来 , 以声明的方式来实现事务管理 . 事务管理作为一种横切关注点 , 可以通过 AOP 方法模块化 . Spring 通过 Spring AOP 框架支持声明式事务管理 .

Spring 中的事务管理器

• Spring 从不同的事务管理 API 中抽象了一整套的事务机制 . 开发人员不必了解底层的事务 API, 就可以利用这些事务机制 . 有了这些事务机制 , 事务管理代码就能独立于特定的事务技术了 .

• Spring 的核心事务管理抽象是 PlatformTransactionManager这个接口。它为事务管理封装了一组独立于技术的方法 . 无论使用 Spring 的哪种事务管理策略 ( 编程式或声明式 ), 事务管理器都是必须的。

Spring 中的事务管理器的不同实现（Mybatis的事务管理器是啥？？？）

•事务管理器以普通的 Bean 形式声明在 Spring IOC 容器中

用 @Transactional 注解声明式地管理事务

• 除了在带有切入点 , 通知和增强器的 Bean 配置文件中声明事务外 , Spring 还允许简单地用 @Transactional 注解来 标注事务方法 .

• 为了将方法定义为支持事务处理的 , 可以为方法添加 @Transactional 注解 . 根据 Spring AOP 基于代理机制 , 只能标注公有方法 .

• 可以在方法或者 类级别上 添加 @Transactional 注解 . 当把这个注解应用到类上时 , 这个类中的所有公共方法都会被定义成支持事务处理的 .

• 在 Bean 配置文件中只需要启用 < tx:annotation-driven > 元素 , 并为之指定事务管理器就可以了 .

• 如果事务处理器的名称是 transactionManager , 就可以在 < tx:annotation-driven > 元素中省略 transaction-manager 属性 . 这个元素会自动检测该名称的事务处理器 .

配置文件示例代码：

用事务通知（xml文件配置）声明式地管理事务

• 事务管理是一种横切关注点

• 为了在 Spring 2.x 中启用声明式事务管理 , 可以通过 tx Schema 中定义的 < tx:advice > 元素声明事务通知 , 为此必须事先将这个 Schema 定义添加到 <beans> 根元素中去 .

• 声明了事务通知后 , 就需要将它与切入点关联起来 . 由于事务通知是在 < aop:config > 元素外部声明的 , 所以它无法直接与切入点产生关联 . 所以必须在 < aop:config > 元素中声明一个 增强器 通知与切入点关联起来 .

• 由于 Spring AOP 是基于代理的方法 , 所以只能增强公共方法 . 因此 , 只有公有方法才能通过 Spring AOP 进行事务管理 .

示例代码：

事务传播属性

• 当事务方法被另一个事务方法调用时 , 必须指定事务应该如何传播 . 例如 : 方法可能继续在现有事务中运行 , 也可能开启一个新事务 , 并在自己的事务中运行 .

• 事务的传播行为可以由传播属性指定 . Spring 定义了 7 种类传播行为：最常用的是required 和 required_new！其它基本不用。REQUIRED是默认传播行为。

REQUIRED 传播行为

• 当 bookService 的 purchase() 方法被另一个事务方法 checkout() 调用时 , 它默认会在现有的事务内运行 . 这个默认的传播行为就是 REQUIRED. 因此在 checkout() 方法的开始和终止边界内只有一个事务 . 这个事务只在 checkout() 方法结束的时候被提交。

• 事务传播属性可以在 @Transactional 注解的 propagation 属性中定义