@Transaction事务导致的mysql连接耗尽源码分析

news2024/12/24 8:24:13

背景：

@Transaction注解是我们在日常的写代码过程中最常使用的事务注解了，本文就从spring源码的角度解析下这个注解的执行过程，以便分析为什么使用事务比正常的单sql执行更容易导致连接池耗尽

源码追踪：

本文假定使用PROPAGATION_REQUIRED (默认)的事务传播，@Transaction的执行过程的伪代码如下所示：

1.从mysql连接池中获取一条db连接,自此该连接被绑定到当前事务中.
2.执行connection.setAutoCommit(false)，即关闭自动事务提交功能
3.执行@Transaction注解的方法，如果执行中途有回滚类的异常，那么走第4步的逻辑，否认走第5步的逻辑
4.执行connection.rollback异常回滚sql操作
5.执行正常的connection.commit事务提交
6.恢复数据库连接的connection.setAutoCommit(true)的自动事务提交功能
7.把connection数据库连接归还给连接池中

TransactionAspectSupport类几乎实现了以上的所有伪代码
在这里插入图片描述
以上就是@Transaction注解的大概代码执行流程

问答：

1.为什么大事务会引起db连接池耗尽
答：从源码中明显可以看出，再执行事务之前获取到的数据库连接会一直持有直到事务结束，这期间该连接是不会释放的，所以大事务容易引起DB连接池耗尽

2.@Transaction异常回滚后，外层调用@Transaction的方法还能获取到异常对象吗？
在这里插入图片描述
看图，显然，sql回滚后还是会把异常向外抛出.

3.同一类中方法调用@Transaction注解的事务方法无效？

是的，而且不管这个类是JDK动态代码实现的AOP还是CGLIB动态修改类实现的AOP，同一个类内方法调用另一个事务方法就是无效

@Transactional(rollbackFor = {Exception.class})
public boolean insertException() {
    boolean saveSuccess = dao.insert(record) > 0;
    System.out.println(1/0);
    return saveSuccess;
}

public boolean insertCaller(Integer ruleId, Integer ruleType) {
    return insertException(ruleId, ruleType);
}