java - 不活动期后连接超时问题

Question

我们有一个使用 hibernate 作为 ORM 工具的 api，我们使用 c3p0 作为连接池处理程序。我们在负载下没有问题。但是，当 api 处于非 Activity 状态一天左右时，我们会遇到“无法获得连接”异常。因此，如果周末没有人使用该 API，我们将在星期一早上收到连接错误。

Caused by: java.sql.SQLException: An attempt by a client to checkout a Connection has timed out.

我们使用mysql作为数据库。在我的研究中，我了解到 mySQL 使连接在 8 小时左右后失效。连接池可能会向客户端发出过时的连接，因此会出现客户端的连接超时异常。

目前我们没有在C3Po中配置任何连接测试。比方说，如果我使用 IdleTestPeriod 在池将连接提供给客户端之前测试连接。那么，如果我的所有连接在某个时间点都未通过测试，会发生什么情况？是否会从池中删除那些失败的连接并再次生成新的 Activity 连接？

目前，这是我们正在使用的 c3p0 设置。这个问题还有其他可能的原因吗？

<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
        <property name="driverClass" value="${----}"/>
        <property name="jdbcUrl" value="${----}"/>
        <property name="user" value="${----}"/>
        <property name="password" value="${------}"/>
        <property name="minPoolSize" value="5"/>
        <property name="acquireIncrement" value="5" />
        <property name="maxPoolSize" value="125" />
        <property name="maxStatements" value="10" />
        <property name="maxIdleTime" value="180" />
        <property name="maxIdleTimeExcessConnections" value="30" />
        <property name="checkoutTimeout" value="3000" />
        <property name="preferredTestQuery" value="SELECT 1" />
    </bean>

Answer 1

所以您设置了 3 秒(3000 毫秒)的 checkoutTimeout。那就是您看到的异常。客户端只允许等待三秒钟以从池中 check out 连接；如果三秒不够，他们会看到您的异常。

问题是，为什么客户要花这么长时间才能获得连接？通常检查连接是一个非常快速的操作。但是，如果所有连接都被 check out ，那么客户端必须等待(缓慢的)从数据库中获取连接。

您已将池配置为非常积极地剔除连接。如果空闲时间超过 maxIdleTimeExcessConnections=30 秒，minPoolSize=5 以上的任何数量的连接都将被销毁。然而，您的池配置为大规模爆发:maxPoolSize=125。假设您的应用程序安静了一段时间，然后收到来自客户端的大量连接请求。池将很快耗尽连接并开始获取，以 acquireIncrement=5 的突发形式。但是，如果突然有 25 个客户端，而池中只有 5 个连接，则第 25 个客户端可能会在获取连接之前超时。

您可以做很多事情。这些调整是可分离的，您可以根据需要混合或匹配。

1. 不那么积极地剔除空闲的“过剩”连接，因此一般来说，您的池有一定的容量来处理突发请求。您可能会完全放弃 maxIdleTimeExcessConnections，并让连接在 maxIdleTime=180 秒停用后慢慢消失。 (缺点？在不活动期间，资源占用量更大，持续时间更长。)

2. 将 minPoolSize 设置为更高的值，这样池就不太可能看到连接太少的 Activity 爆发。 (缺点？更大的永久资源足迹。)

3. 从您的配置中删除 checkoutTimeout。 c3p0 的默认设置是允许客户端无限期地等待连接。 (缺点？也许您更希望客户快速报告失败，而不是等待可能的成功。)

我认为您观察到的问题与连接测试或 MySQL 超时本身没有太大关系，但这并不意味着您不应该处理这些问题。我会听从 nobeh 关于 MySQL 重新连接问题的建议。 (我不是 MySQL 的大用户。)您应该考虑实现连接测试。您有一个 preferredTestQuery，因此测试应该相当快。我通常的选择是使用 testConnectionOnCheckin 和 idleConnectionTestPeriod。参见 http://www.mchange.com/projects/c3p0/#configuring_connection_testing

祝你好运!