记录一个@Transaction注解引发的bug

记录一个@Transactional(readOnly = true)注解引发的bug

一、问题代码和报错

1-1 问题代码模拟

引发这个问题的三大要素分别是:

  • 事务注解
  • 任意数据库操作
  • 数据库操作后执行耗时业务(耗时超过数据库配置的超时时间)
java 复制代码
//1.这里是问题的核心之一:开启事务注解
@Transactional(readOnly = true)
public void testBug() {
    //2.这里是随便一个需要连接数据库的查询操作
    PageInfo<Needs> page = getPage(new NeedsQuery());
    //3.这里用睡5分钟来模拟执行业务
    try {
        Thread.sleep(5*60*1000);
    } catch (InterruptedException e) {
        throw new RuntimeException(e);
    }
    //这里表示方法执行完成
    System.out.println("结束");
}

1-2 报错

java 复制代码
Caused by: com.mysql.cj.jdbc.exceptions.CommunicationsException: The last packet successfully received from the server was 300,018 milliseconds ago. The last packet sent successfully to the server was 300,018 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.
	at com.mysql.cj.jdbc.exceptions.SQLError.createCommunicationsException(SQLError.java:174)
	at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:64)
	at com.mysql.cj.jdbc.ConnectionImpl.commit(ConnectionImpl.java:811)
	at com.zaxxer.hikari.pool.ProxyConnection.commit(ProxyConnection.java:387)
	at com.zaxxer.hikari.pool.HikariProxyConnection.commit(HikariProxyConnection.java)
	at org.springframework.jdbc.datasource.DataSourceTransactionManager.doCommit(DataSourceTransactionManager.java:333)
	... 107 common frames omitted

二、原因分析

先一句话总结报错原因:业务执行完成后提交事务时,数据库连接已经关闭,提交失败报错。

然后来细说这个报错是怎么产生的。

2-1 前提:MySQL配置

首先必须提到MySQL数据库的两个配置:

interactive_timeout:mysql在关闭一个非交互的连接之前所要等待的秒数
wait_timeout:mysql在关闭一个交互的连接之前所要等待的秒数

连接MySQL后通过命令可以查询到这两个配置的值:在没有配置的情况下,一般是默认28800秒,即8小时。

mysql 复制代码
SHOW VARIABLES LIKE '%timeout%';

也就是,创建一个连接后,8小时没有通过这个连接执行任意操作,MySQL数据库为了节省资源,就会在数据库端断开这个连接。

2-2 报错分析

从报错日志可以看出:大致意思是数据库连接超时,在提交事务的时候报错。

java 复制代码
at org.springframework.jdbc.datasource.DataSourceTransactionManager.doCommit(DataSourceTransactionManager.java:333)

这里的连接超时,就是指上面提到的:数据库连接超过了配置里设置的超时时间,自动断开了连接。

查询了下生产数据库的连接配置,发现我设置的超时时间是180秒。

把这个过程连贯地描述一下,也就是:我在创建了一个数据库连接之后,一段时间之后,再次使用这个数据库连接,发现连接已经断开,于是使用失败,程序抛出异常,于是抛出了这段错误日志。

java 复制代码
The last packet successfully received from the server was 300,018 milliseconds ago. The last packet sent successfully to the server was 300,018 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.

按照日志里的描述,我是在超过了300秒之后再去使用这个连接,这当然是超过了我MySQL配置里的180秒的,程序的异常由此产生。

那么,为什么我要在把连接闲置了这么长一段时间之后,再次通过这个连接操作数据库呢。

这口锅就要扣到标题所说的注解@Transactional(readOnly = true)上了。

这里本来是个查询方法,不涉及改库的操作。但由于在方法头上加了@Transactional(readOnly = true)注解,意味着开启只读事务,所以这个方法涉及到的数据库操作,就会被事务管理。

所以原本的过程:

读数据库-》执行业务,

在事务的管理下,变成了:

开启事务-》读数据库-》执行业务-》提交事务。

异常的发生就在最后一步的 提交事务 上。

最初开启事务时创建了数据库连接-》执行了超过180秒的业务-》程序试图用之前的数据库连接去提交事务-》而连接已经断开。

提交事务这一操作就会发生异常,报错由此产生。

三、解决方案

这里可以从两个方面去解决:

方案1:去掉事务

业务原本是读库操作,并没有必须开启事务的必要性,最简单的做法,当然是去掉事务注解,这样自然就不会因为提交事务时数据库连接已断开而报错。

方案2:修改MySQL配置

归根结底,异常的产生是由于数据库连接自动断开,那么我们按照错误日志的提示,把这个自动断开的时间设置得长一点,也能阻止异常的发生。

注意:直接修改查询到的MySQL配置只能改变本次连接里的设置,要想永久修改,必须在配置文件里修改后重启MySQL

ini 复制代码
[mysqld]
wait_timeout=180 # 这里改成你需要的时间,单位秒
interactive_timeout=180 # 这里改成你需要的时间,单位秒
相关推荐
NE_STOP2 小时前
MyBatis-配置文件解读及MyBatis为何不用编写Mapper接口的实现类
java
数据组小组3 小时前
免费数据库管理工具深度横评:NineData 社区版、Bytebase 社区版、Archery,2026 年开发者该选哪个?
数据库·测试·数据库管理工具·数据复制·迁移工具·ninedata社区版·naivicat平替
后端AI实验室7 小时前
用AI写代码,我差点把漏洞发上线:血泪总结的10个教训
java·ai
用户8307196840827 小时前
MySQL 查询优化 30 条封神技巧:用好索引,少耗资源,查询快到飞起
mysql
程序员清风8 小时前
小红书二面:Spring Boot的单例模式是如何实现的?
java·后端·面试
belhomme8 小时前
(面试题)Redis实现 IP 维度滑动窗口限流实践
java·面试
Be_Better9 小时前
学会与虚拟机对话---ASM
java
Nyarlathotep01139 小时前
事务隔离级别
sql·mysql
悟空聊架构9 小时前
基于KaiwuDB在游乐场“刷卡+投币”双模消费系统中的落地实践
数据库·后端·架构
IvorySQL9 小时前
PostgreSQL 技术日报 (3月4日)|硬核干货 + 内核暗流一网打尽
数据库·postgresql·开源