深入理解Spring事务传播机制-原理与实例说明
事务传播机制
简化记忆版本
- REQUIRED:有事务加入，没有事务创建，Spring默认
- MANDATORY:必须在事务中被调用，没有抛异常
- SUPPORTS:有事务加入，没有以非事务运行
- NOT_SUPPORTED:不需要事务，有事务则挂起，避免回滚。例如记日志，避免日志信息回滚
- REQUIRES_NEW:当前方法创建新事务运行，如果有事务则挂起，主要是为了控制敏感资源事务粒度，避免从时间锁，可以局部回滚
- NESTED:如果有事务，加入事务但是记录保存点，如果没有事务创建事务，主要作用局部回滚(通过savepoint实现)，不挂起已有事务
- NEVER:该方法不应该在事务中运行，如果存在事务则抛异常
不同传播机制之间的区别
REQUIRED与MANDATORY:REQUIRED没有事务自己创建，MANDATOR没有事务异常。
| 传播机制 | 区别 |
|---|---|
| REQUIRED与MANDATORY | 方法没有事务，REQUIRED自己创建；而MANDATOR抛出异常 |
| REQUIRED与REQUIRES_NEW | 方法在事务中执行，REQUIRED加入该事务；REQUIRES_NEW会挂起已有的事务，创建自己的事务 |
| NESTED与REQUIRES_NEW | 方法在事务中执行NESTED加入该事务，并记录回滚点；REQUIRES_NEW挂起已有事务，创建新事务 |
| NESTED与REQUIRED | 都是有事务加入，没有事务创建，但NESTED比REQUIRED多了保存回滚点 |
| NOT_SUPPORTED与NEVER | 方法在事务中被调用NOT_SUPPORTED会挂起事务，而NEVER会抛出异常 |
| MANDATORY与NEVER | 两者相反， 没有在事务中MANDATORY抛出异常，而有事务NEVER抛出异常 |
| SUPPORTS与没有传播机制注解 | 感觉没有区别，发现有区别的朋友可以补充一下 |
当SUPPORTS方法被NEVER、NOT_SUPPORTED、没有@Transactional注解这些方法调用，不会有事务，和不加注解效果一样。
当SUPPORTS方法被REQUIRED、MANDATORY、REQUIRES_NEW、NESTED这些方法调用时，加入事务，和不加注解效果也一样。
所以SUPPORTS应用场景是啥？
问题测试
REQUIRED与MANDATORY
@Service
public class ServiceA
{
@Transactional(propagation = Propagation.REQUIRED)
public void methodA(){
methodB();
}
@Transactional(propagation = Propagation.MANDATORY)
public void methodB(){}
}
@Service
public class ServiceC
{
@Resource
private ServiceA serviceA;
public void methodC(){
// 创建一个事务执行方法A
serviceA.methodA();
// methodB是MANDATORY，但是methodC没有事务，所以直接抛出异常
serviceA.methodB();
}
}
NESTED回滚测试
@Service
public class ServiceA
{
@Transactional(propagation = Propagation.NESTED)
public void methodA(){
// 数据库操作
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
}
}
@Service
public class ServiceB
{
@Transactional(propagation = Propagation.NESTED)
public void methodB(){
// 数据库操作
}
}
@Service
public class ServiceC
{
@Resource
private ServiceA serviceA;
@Resource
private ServiceB serviceB;
@Transactional
public void methodC(){
serviceA.methodA();
serviceB.methodB();
}
}
上面的操作哪些会回滚？
答案是：
methodA会回滚
methodB不回滚
因为methodA、methodB是NESTED，记录了回滚点，所以只有methodA被回滚。
NESTED传播测试
做一点小变动，如果把methodA上的@Transactional(propagation = Propagation.NESTED)注解去掉呢？
放在methodC方法上会怎样？
@Service
public class ServiceA
{
public void methodA(){
// 数据库操作
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
}
}
@Service
public class ServiceB
{
@Transactional(propagation = Propagation.NESTED)
public void methodB(){
// 数据库操作
}
}
@Service
public class ServiceC
{
@Resource
private ServiceA serviceA;
@Resource
private ServiceB serviceB;
@Transactional(propagation = Propagation.NESTED)
public void methodC(){
serviceA.methodA();
serviceB.methodB();
}
}
答案是：
methodA会回滚
methodB会回滚
因为methodA没有注解，就相当于使用的是methodC的事务，并且所以回滚点在methodC，
methodB也使用了methodC的事务，也设置了回滚点，但是在methodA中回滚，整个事务都回滚了。
如何只回滚methodB，不回滚methodA呢？
答案是：
将methodA的TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()放在方法放methodB中就可以。
当methodB是NESTED的时候，在其中回滚，因为有回滚点，所以只会回滚methodB中操作，不会影响methodC方法。
REQUIRES_NEW回滚测试
再来一点点小变动：
将methodB的NESTED换为REQUIRES_NEW会怎样？
@Service
public class ServiceA
{
public void methodA(){
// 数据库操作
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
}
}
@Service
public class ServiceB
{
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void methodB(){
// 数据库操作
}
}
@Service
public class ServiceC
{
@Resource
private ServiceA serviceA;
@Resource
private ServiceB serviceB;
@Transactional(propagation = Propagation.NESTED)
public void methodC(){
serviceA.methodA();
serviceB.methodB();
}
}
答案是：
methodA会回滚
methodB不回滚
把methodB的NESTED换为REQUIRES_NEW就可以，因为REQUIRES_NEW为挂起原有事务，并创建新的事务，
所以methodC的事务不会影响到methodB的事务。
异常对不同传播机制回滚影响测试
再来一点点小变动：
将methodA中的手动回滚TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
换为：throw new RuntimeException(“我要异常”);
会怎样呢？
@Service
public class ServiceA
{
@Transactional(propagation = Propagation.NESTED)
public void methodA(){
// 数据库操作
throw new RuntimeException("我要异常");
}
}
@Service
public class ServiceB
{
@Transactional(propagation = Propagation.NESTED)
public void methodB(){
// 数据库操作
}
}
@Service
public class ServiceC
{
@Resource
private ServiceA serviceA;
@Resource
private ServiceB serviceB;
@Transactional
public void methodC(){
serviceA.methodA();
serviceB.methodB();
}
}
答案是：
methodA会回滚
methodB会回滚
如果异常这一次把methodB的传播机制换NESTED为REQUIRES_NEW还能生效吗？
答案是：不能。
很难理解？
的确比较绕，其实很简单，因为异常了，根本就没有执行到methodB，就直接回滚了。
事务内部调用
再来点简单点的问题。
// 调用 1
public class ServiceA
{
@Transactional
public void methodA(){
userMapper.insertSelective(UserTO.builder()
.username("tim")
.email("[email protected]")
.build());
methodB();
}
public void methodB(){
eventLogMapper.insertSelective(EventLogTO.builder()
.type((short) 1)
.message("创建用户")
.build());
}
}
这个事务会生效吗？
答案是：会，很简单，在方法methodA中调用methodB，其实和把methodB的方法体放入methodA方法体中没有什么一样。
// 调用2
public class ServiceA
{
public void methodA(){
methodB();
}
@Transactional
public void methodB(){}
}
这个事务会生效吗？
答案是：不能，很多朋友都知道，因为没有走代理，Spring的事务必须通过代理。
如何让它生效呢？
不要直接调用，通过Spring的方式来呗。
@EnableAspectJAutoProxy(exposeProxy = true)
ServiceA serviceA = (ServiceA)AopContext.currentProxy();
serviceA.methodB();
或者：
@Resource
private ApplicationContext applicationContext;
ServiceA serviceA = applicationContext.getBean(this.getClass());
serviceA.methodB();
或者：
@Service
public class ServiceA
{
@Resource
private ServiceB serviceB;
public void methodA(){
serviceB.methodB();
}
}
@Service
public class ServiceB
{
@Transactional
public void methodB(){}
}
SQL
CREATE TABLE user (
id bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',
username varchar(30) DEFAULT NULL COMMENT '姓名',
age smallint(5) unsigned DEFAULT NULL COMMENT '年龄',
sex tinyint DEFAULT -1 COMMENT '性别(-1-保密,1-男,2-女)',
email varchar(255) DEFAULT NULL COMMENT '邮箱',
status tinyint DEFAULT 1 COMMENT '状态(-1-删除,1-正常)' ,
create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='用户表';
CREATE TABLE event_log (
id bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',
message varchar(255) DEFAULT NULL COMMENT '信息',
type smallint(5) unsigned DEFAULT NULL COMMENT '事件类型',
create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='事件日志';