MySql connector/J中的autoReconnect和autoReconnectForPools有什么区别？

在MySql的连接器J驱动程序的配置参考中,发出了一个关于使用autoReconnect属性的警告.我按照说明操作,增加了服务器的wait_timeout.由于我正在使用DBCP(我正在考虑在阅读关于DBCP的Stackoverflow上的几篇帖子后转到c3po),是否可以使用autoReconnectForPools属性？在DBCP或任何连接池下启用时,它实际上做了什么？

1> David Rabino..：

---

autoReconnect将向客户端抛出SQLException,但会尝试重新建立连接.

autoReconnectForPools将尝试在每次执行SQL之前ping服务器.

我过去遇到过dbcp的很多问题,尤其是断开连接.大多数是通过转移到c3p0解决的.请注意,mysql驱动程序具有c3p0的连接测试程序(com.mysql.jdbc.integration.c3p0.MysqlConnectionTester).

此外,您可能需要检查一下:JDBC的连接池选项:DBCP与C3P0

---

通常，更现代的池，例如HikariCP或Tomcat DBCP将使用Connection.isValid（）方法。还有一个只有MySQL才能识别的“特殊”查询，“ / * ping \ * /”（必须“精确”），这会使MySQL对服务器使用轻量级的“ ping”。我相信isValid（）的实现应该仍然更加高效，因为解析器仍必须处理“ / * ping \ * /”查询。

2> rustyx..：

---

MySQL的autoReconnect功能已被弃用,因为它有很多问题(参考:官方文档).

autoReconnectForPools与此无关autoReconnect,它更多地与- autoCommit并且reconnectAtTxEnd- 当所有3个都是true,它将在每个事务结束时ping服务器并在需要时自动重新连接.

DBCP的连接验证是不完美的 - 即使testOnBorrow设置了它,它有时会从池中返回断开的连接(更不用说在每次借用之前测试连接效率非常低).

根据这篇文章,HikariCP似乎是一个更好的池实现,因为它能够使用isValid()比运行测试查询快得多的JDBC4 API,并且专门设计为永远不会将断开的连接返回到客户端应用程序.