@Transactional 失效的 7 种场景：第 5 种最难排查

一、事故现场

线上有个工单状态更新接口。先更新工单状态，再写操作日志。两个操作要在同一个事务里要么都成功，要么都回滚。

java @Service public class TicketService { @Autowired private TicketMapper ticketMapper;

@Autowired
private OperationLogMapper logMapper;@Transactional
public void updateTicketStatus {
ticketMapper.updateStatus;// 更新工单状态
logMapper.insert);// 写操作日志
}

}

测试环境跑得好好的。上线后某天工单状态更新了但操作日志没写进去。事务没回滚，@Transactional 失效了。

再看排查发现，这个方法被同一个类的另一个方法调用了@Transactional 的 AOP 代理没生效。

二、@Transactional 为什么会失效

@Transactional 的原理是 Spring AOP 动态代理。Spring 在 Bean 初始化时生成一个代理对象，代理对象在方法执行前后管理事务的开启和提交。话说回来，

凡是绕过代理对象的调用。@Transactional 都不生效。

这个原理决定了以下 7种失效场景,下面逐个讲解:

三、7种失效场景

从场景1来看。自调用

java @Service public class TicketService { @Transactional public void updateTicketStatus { ticketMapper.updateStatus;logMapper.insert);}

public void doUpdate {
// 自调用：this 调用，走的是原始对象不是代理对象
this.updateTicketStatus;// @Transactional 不生效！}

方法: java //方案1这方面，拆分到另一个Service中保证通过Spring容器获取Bean实例进行方法间互相调用

@Service public class TicketTxService { @Autowired private TicketService ticketService;@Autowired private LogMapper logMapper;

@Transactional public void updateTicketStatus{ //业务逻辑... } }

@Service public class TicketCoreService{ @Autowired private TicketTxService txSvc;public void processOrder{ txSvc.updateTicketStatus;//正常走AOP代理链条!说起来，} }

//方案2的观点是。注入自己的代理 @Service public class TicketAutoProxy{ @Autowired private TicketAutoProxy self;

public void update{ self.doSomething;//self已经是Spring创建的AOP动态代理解引例! }

@Transactionl public void doSomething{...} }

场景2的观点是，方法不是public修饰符

java @Service public class InvalidAccessControlDemo{ //默认包级访问权限!按理说，Spring AOP只能提高Public修饰符方法!protected void invalidMethod{ throw new RuntimeException;} }

方法: 必须显式声明为公共接口: java //正确做法的观点是，必须使用Public修饰符!@Override public int deleteByPrimaryKey{ ... }

说到场景3，异常被catch吞噬

java @Service class TrapHandlerExample{ @Transactionl public Result executeTask{ try{ criticalOperation;}catch{ logger.error;return Result.fail);//吃掉异常导致事务未回滚!说起来，} } }

• AOP依赖异常传播机制触发回滚行为;
• 若内部try-catch结构吞噬所有异常 - Spring框架将感知不到错误发生;不过，
• 结果:即使数据库错误仍会提交事务!

方法: 完整传播异常信息: java //正确做法1: 原样抛出所有运行时异常 try{...}catch{throw e;}

//正确做法2: 包装成运行时异常并重新抛出 try{...}catch{ throw new RuntimeException,sqlEx);}

//正确做法3: 指定具体需要处理而不需要回滚的检查型异常类型 @Transactionl

场景4这方面，非RuntimeException默认不回滚

java @Service class UnexpectedCheckedBehavior{

 /* 默认仅RuntimeException及其子类会触发事务回滚。检查型IOException等其他类型需要显式指定 */
@Transactionl(
rollbackFor={IOException.class},//显式指定检查型异常也需要回滚处置！noRollbackFor={InterruptedException.class}/* 排除特定情况 */
)
public File processFile throws IOException{
if)throw new FileNotFoundException;...
return processedFile;}

• AOP框架底层依赖于PlatformTransactionManager判断何时应进行Rollback;
• 默认仅针对UncheckedExceptions触发!，

关键点: - rollbackFor属性接受Class数组作为参数可覆盖默认行为 - noRollbackFor属性则相反 - 排除某些特殊情况 - propagation属性可配合使用控制传播模式

至于场景5，REQUIRES_NEW传播行为误导

@Autowired ParentContext parentCtx;

//ParentContext.java : @Transactionl//注意区别于REQUIRES_NEW！void beginWork{...};

//ChildContext.java : @Autowired ChildContext childCtx;childCtx.processData;}

@Autowired ChildContext childCtx;

//ChildContext.java : void processData{ /* 内层独立提交/回滚,外部主流程继续执行 */ }

''
''
'' '''' '''''' '' ''