春季应用程序在8小时后失去与MySql的连接。如何正确配置?

我有一个Spring应用程序,我相信它使用DBCP连接池连接到MySql数据库。我说相信,因为这不是一个我非常擅长的领域,如果一切都设置正确,我就不会乐观。我在运行应用程序时没有问题,一切正常。问题在一夜之间发生。该应用程序的使用并不多,一夜之间它显然失去了与MySql的连接。我研究了一下,发现MySql有一个8小时的窗口,然后它断开连接或其他什么。我对此很好,但是当用户尝试在早上登录时,他们会收到如下错误:

通信链路故障。最后一个数据包在 60,000,000ms 前成功接收。最后一个数据包在 15 毫秒前成功设置。

这就是问题所在。我需要他们能够在早上重新连接而不会遇到此问题。我似乎能够修复它的唯一方法是弹跳Tomcat服务器。通过研究它,似乎DBCP池应该能够以某种方式防止这种情况,但我找不到有关如何配置它的可靠信息来源。我希望这里的某个人能为我提供一些见解。这是我当前的配置,全部在Spring xml文件中完成:

应用数据.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="
    http://www.springframework.org/schema/beans 
    http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
    http://www.springframework.org/schema/tx 
    http://www.springframework.org/schema/tx/spring-tx-3.0.xsd
    http://www.springframework.org/schema/aop 
    http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
    http://www.springframework.org/schema/context
    http://www.springframework.org/schema/context/spring-context-3.0.xsd">

<context:annotation-config />
<context:component-scan base-package="com.vz.sts.domain" />
<context:component-scan base-package="com.vz.sts.persistence" />
<context:component-scan base-package="com.vz.sts.service" />

<bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor" />

<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
    <property name="dataSource" ref="dataSource" />
    <property name="jpaVendorAdapter">
        <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
            <property name="database" value="MYSQL" />
            <property name="showSql" value="true" />
        </bean>
    </property>
</bean>

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
    <property name="driverClassName" value="com.mysql.jdbc.Driver" />
    <property name="url" value="jdbc:mysql://localhost:3306/app" />
    <property name="username" value="root" />
    <property name="password" value="admin" />
    <property name="initialSize" value="5" />
</bean>

<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
    <property name="entityManagerFactory" ref="entityManagerFactory" />
</bean>

<bean id="jdbcUserService" class="org.springframework.security.provisioning.JdbcUserDetailsManager">
    <property name="dataSource" ref="dataSource"/>
    <property name="authenticationManager" ref="authenticationManager"/>
</bean>

<bean id="saltSource" class="org.springframework.security.authentication.dao.ReflectionSaltSource">
    <property name="userPropertyToUse" value="username" />
</bean>

<tx:annotation-driven />
</beans>

我不确定我需要添加哪些特定属性才能允许应用重新连接到数据库。我不介意它是否在几个小时后关闭连接,但它应该自动重新连接,而不是抛出这样的错误。我甚至也不肯定它实际上被设置为使用连接池。所以任何帮助将不胜感激,谢谢。

更新

我找到了这个页面,我认为我需要做的就是添加 ValidationQuery 属性。任何人都可以验证这是否会产生欲望影响,同时将其他所有内容保留为默认值?我相信这将利用DBCP的testOnBorrow方面。我不完全理解解释说testOnBorrow做了什么,但我认为这将做我想要的。有人确认吗?谢谢。


答案 1

简短的答案是它应该足够了。DBCP 支持在从连接池借用时测试连接(默认值),但也支持在返回时测试和空闲时测试。

同样值得了解的是,这里可能出了什么问题。这听起来像是您的Tomcat服务器和数据库之间的某些东西在超时后(例如路由器或防火墙)丢弃了空闲连接。这样做的问题是,Tomcat 认为它仍然具有有效的连接,尝试对连接执行一些工作并失败,但保持连接处于活动状态并将其返回到池中。现在,如果从池中为数据库提供相同的断开连接,则与数据库通信的任何进一步尝试都将失败。

我认为是迈克尔·尼加德(Michael Nygard)出色的《释放它!》(Release It!)一书在他的一个战壕故事中描述了这种情况。

您还需要研究MySQL如何清理死连接,因为当Tomcat在8小时后失去连接时,DB也将不知道连接失败。

最后一点,如果您使用的是Tomcat 7,请切换到他们的新连接池,因为它提供了比DBCP更好的性能。


答案 2

我的朋友,DBCP做了一个他无法兑现的承诺。呵呵。我发现自己遇到了这个问题,它归结为一些新的防火墙最近放在中间,切断空闲时间超过X小时的空闲连接。因此,Db 无法通知我的客户端(及其套接字)连接正在关闭并且套接字保持打开状态,因此池无法知道该连接不可用。结果:早上的第一次查询尝试失败,出现超时,而第二次查询尝试按预期工作。即使使用verificationQuery,DBCP也没有检查已经有效的conn(不要问我为什么,我只是发现了这一点)

解决方案 1?由于这是一个生产环境(是的,很多汗水),快马是创建一个单独的线程,每隔一段时间使用池向数据库发送一个确定的查询。X/4 小时。它阻止了全新的防火墙/ WAF切断我的套接字连接!

解决方案 2?检查基础结构。检查连续性。检查网络接口的速度和模式(例如全双工,100M)的一致性。检查数据库服务器设置(无网卡节能呵呵)。也许保持溶液1中的探头工作。

编辑。testOnBorrow 和 validationQuery 應該在正常情況下工作。使用逻辑通道和物理套接字对池进行映像,顺便说一下客户端和服务器。testOnBorrow 在将通道提供给您的请求之前,会检查该通道是否有效。它使用验证查询来执行此操作。


推荐