连接超时是在不活动期后

我们有一个使用hibernate作为ORM工具的api,我们使用c3p0作为连接池处理程序。 我们在负载下没有问题。 但是,当api处于非活动状态一天左右时,我们就会遇到“无法获取连接”的exception。 因此,如果周末没有人使用api,我们会在周一早上收到连接错误。

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

我们使用mysql作为数据库。 在我的研究中,我知道mySQL在8小时左右后连接失效。 连接池可能会向客户端发出过时的连接,从而导致客户端的连接超时exception。

目前,我们没有在C3Po中配置任何连接测试。 可以说,如果我在池中将它们提供给客户端之前使用IdleTestPeriod来测试连接。 那么如果我的所有连接在某个时间点都未通过测试会发生什么? 是否会从池中删除这些失败的连接,并再次生成新的活动连接?

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

               

谢谢您的帮助

所以你有一个3秒(3000毫秒)的checkoutTimeout。 那是你看到的例外。 客户端只允许等待三秒钟从池中检出连接; 如果三秒钟还不够,他们会看到你的例外情况。

问题是,为什么客户需要这么长时间才能获得连接? 通常检查一个连接是一个非常快速的操作。 但是如果检出所有连接,则客户端必须等待(缓慢)从数据库获取连接。

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

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

1)剔除空闲的“多余”连接不那么积极,因此通常,您的池有一定的容量来处理突发请求。 您可以完全删除maxIdleTimeExcessConnections,并在maxIdleTime = 180秒不使用之后让Connections缓慢移动。 (下行?在不活动期间更长的资源占用空间)

2)将minPoolSize设置为更高的值,这样池不太可能看到一连串的活动突然连接太少(下行?更大的永久资源占用空间。)

3)从配置中删除checkoutTimeout。 c3p0的默认设置是允许客户端无限期地等待连接。 (下行?也许你更喜欢客户快速报告失败而不是等待可能的成功。)

我不认为您所观察到的问题与连接测试或MySQL超时本身有很大关系,但这并不意味着您不应该处理这些问题。 我将遵循nobeh关于MySQL重新连接问题的建议。 (我不是一个很大的MySQL用户。)你应该考虑实现连接测试。 你有一个首选的测试,所以测试应该相当快。 我通常的选择是使用testConnectionOnCheckin和idleConnectionTestPeriod。 请参阅http://www.mchange.com/projects/c3p0/#configuring_connection_testing

祝你好运!

在MySQL Java Connector的高可用性和集群部分中,查看属性; 特别是autoReconnectautoReconnetForPools 。 使用JDBC连接URL中的属性。 在使用MySQL,Hibernate和C3P0之前,他们帮助了我。 希望这会有所帮助。