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

一、问题代码和报错

1-1 问题代码模拟

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

• 事务注解
• 任意数据库操作
• 数据库操作后执行耗时业务（耗时超过数据库配置的超时时间）

//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 报错

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小时。

SHOW VARIABLES LIKE '%timeout%';

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

2-2 报错分析

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

at org.springframework.jdbc.datasource.DataSourceTransactionManager.doCommit(DataSourceTransactionManager.java:333)

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

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

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

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

[mysqld]
wait_timeout=180 # 这里改成你需要的时间，单位秒
interactive_timeout=180 # 这里改成你需要的时间，单位秒