前言
本项目聚焦高并发的基础知识,至底向上得研究:
- 单机事务模型(Mysql事务)
- 单机事务模型(Spring事务传播 ) <===== 本文坐标
- 单机高并发 (多线程 -> 缓存)
- 集群 ( 集群 -> 分布式 -> 微服务 -> 服务治理)
- 读密集(数据仓库、搜索引擎)
- 写密集(TODO)
项目介绍
github 仓库 (分支 master / isolation / propagation / multithreading)
理念:
- 使用
Spring Boot
和基于Groovy
的测试框架Spock
编写测试用例。 - 证实并发隐患后(脏读、更新丢失、不可重复读、幻读等),用官方文档加以说明解释,并沉淀用例。
- 不合理的解决方案造成死锁,沉淀用例
- 较合理的解决方案,沉淀用例
分支组成
- Spock 与 Spring Boot 集成
master 分支
- Mysql-Innodb 的事务隔离及常用锁
isolation 分支
- Spring 事务传播行为
propagation 分支
<===== 本文坐标 - Java JUC 多线程编程(Doing)
multithreading 分支
- 升级项目为MySQL集群(Todo)
Spring 官方介绍的事务传播行为
事务传播行为官网描述
用于区分声明式事务catch到异常由框架回滚,本文的“回滚”用到编程式事务的API TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()
支持主动回滚。编程式事务官网描述
讨论的模型是 调用方(外层) -> 被调用方(内层)
- 传播行为是发生在两个事务之间,即外层内层都声明了事务保护,只是传播行为可能存在不同。
- 重点关心被调用方的行为即可。只有内层被调用才能让传播行为生效。
- 忽略掉一种讨论:内层抛Exception不catch被外层捕获,内外层的代码都会回滚
required
默认传播行为, 确保当前方法一定处于事务保护中
- 如果调用方不存在事务,则新创建一个事务(只保护自己的代码)
- 如果调用发存在事务,则加入到调用方的事务,即扩大了调用方事务的范围
- 回滚处理
- 外层无事务
- 内层回滚, 只回滚内层代码
- 外层有事务
- 内层回滚 抛出
UnexpectedRollbackException
因为内层加入到外层事务中,形成一个大事务,TransactionAspectSupport.currentTransactionStatus().setRollbackOnly() 会把外层的代码一并提交,内层代码执行完毕,外层代码继续执行。由于声明式事务,外层代码执行结束,会触发一次提交,但是这次提交的事务已经被内层提交了,所以抛异常。
- 外层回滚,内外都回滚
- 内层回滚 抛出
- 外层无事务
requires_new
用于减少事务的粒度,如果不是关键的业务逻辑或是运行出错的逻辑,可以用requires_new
声明与调用方事务隔离。
- 无论调用方是否存在事务,自己都会新增一个事务给自己执行
- 外层无事务
- 内层回滚同
required
- 内层回滚同
- 外层有事务
- 内层回滚,只回滚内层代码,后续不会出现
required
的异常 - 外层回滚,只回滚外层代码
- 内层回滚,只回滚内层代码,后续不会出现
nested
只适用于JDBC。介于required
和 nested
之间,内层事务处于一个“寄生”的状态,他的附加价值是可以减少死锁隐患,后文会提到。
- 外层无事务
- 内层同
required
- 内层同
- 外层有事务
- 内层同
requires_new
- 内层同
requires_new
造成的死锁分析
- 外层事务A对记录record加了写锁
- 外层事务调用了
requires_new
声明的内层事务B - 内层事务B也对record申请加锁请求
由于事务A和事务B属于不同事务,A未提交并持有record的写锁不释放,
事务B一直等待A释放,事务A又等待事务B提交自己才能提交。所以互相等待,造成锁等待超时。
nested
取代 requires_new
减少死锁隐患
nested 声明的内层事务被外层调用,视为“寄生”在外层的事务中。也就不存在事务竞争资源。
同时 nested 支持独立回滚,是由底层JDBC的savepoint 支持,API例子:
transactionTemplate.execute(new TransactionCallbackWithoutResult() {
protected void doInTransactionWithoutResult(TransactionStatus status) {
status.createSavepoint();
status.rollbackToSavepoint();
}
}