org.springframework.transaction.CannotCreateTransactionException: Could not open JDBC Connection for

3 篇文章 0 订阅

Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException

org.springframework.transaction.CannotCreateTransactionException: Could not open JDBC Connection for transaction; nested exception is com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last
 packet successfully received from the server was 369,727,249 milliseconds ago.  The last packet sent successfully to the server was 369,727,249 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.org.springframework.jdbc.datasource.DataSourceTransactionManager.doBegin(DataSourceTransactionManager.java:305)
        at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:378)
        at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:475)
        at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:289)
        at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:98)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
        at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:688)
        at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
        at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:749)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
        at sun.reflect.GeneratedMethodAccessor213.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:190)
        at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:138)
        at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:104)
        at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:892)
        at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:797)
        at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:87)
        at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1039)
        at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:942)
        org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:109)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
        at org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:93)
        at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:109)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
        at com.iboxchain.pub.xlog.core.filter.CidFilter.doFilter(CidFilter.java:88)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
        java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.lang.Thread.run(Thread.java:745)
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 369,727,249 milliseconds ago.  The last packet sent successfully to the server was 369,727,249 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 sun.reflect.GeneratedConstructorAccessor185.newInstance(Unknown Source)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
        at com.mysql.jdbc.Util.handleNewInstance(Util.java:409)
        at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1127)
        at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3983)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2596)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2776)
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2832)

查了下原因,居然是mysql超时设置的问题,由于长时间数据库连接空闲,导致自动断开连接,默认mysql超时时间是 28880秒(8小时),可通过:show global variables like “wait_timeout”; 查看
在这里插入图片描述

解决办法

为了解决这个异常,我们在配置数据库连接池的时候需要做一些检查连接有效性的配置,这里以Druid为例

字段名默认值说明
validationQuery用来检测连接是否有效的sql,要求是一个查询语句,常用select ‘x’。如果validationQuery为null,testOnBorrow、testOnReturn、testWhileIdle都不会起作用。
validationQueryTimeout单位:秒,检测连接是否有效的超时时间。底层调用jdbc Statement对象的void setQueryTimeout(int seconds)方法
testOnBorrowtrue申请连接时执行validationQuery检测连接是否有效,做了这个配置会降低性能。
testOnReturnfalse归还连接时执行validationQuery检测连接是否有效,做了这个配置会降低性能。
testWhileIdlefalse建议配置为true,不影响性能,并且保证安全性。申请连接的时候检测,如果空闲时间大于timeBetweenEvictionRunsMillis,执行validationQuery检测连接是否有效。
timeBetweenEvictionRunsMillis1min有两个含义:1) Destroy线程会检测连接的间隔时间,如果连接空闲时间大于等于minEvictableIdleTimeMillis则关闭物理连接。2) testWhileIdle的判断依据,详细看testWhileIdle属性的说明

为了避免空闲时间过长超过最大空闲时间而被断开,我们设置三个配置:

 timeBetweenEvictionRunsMillis: 28000
 validationQuery: select 1 from dual
 testWhileIdle: true

其中timeBetweenEvictionRunsMillis需要小于mysql的wait_timeout。

但是这种方法无法避免重启的情况,不过一般数据库不会频繁重启,影响不大,如果非得频繁重启,可以通过设置testOnBorrow,即申请连接的时候先试一试连接是否可用,不过带来的影响就是性能降低,需要根据实际需求合理取舍。

网上说的其他解决办法:(我的没有生效)

一种. 如果不用hibernate的话, 则在 connection url中加参数: autoReconnect=true

jdbc.url=jdbc:mysql://ipaddress:3306/database?autoReconnect=true&autoReconnectForPools=true

二种。用hibernate的话, 加如下属性: 
    <property name="connection.autoReconnect">true</property>
    <property name="connection.autoReconnectForPools">true</property>
    <property name="connection.is-connection-validation-required">true</property>


三。要是还用c3p0连接池: 
    <property name="hibernate.c3p0.acquire_increment">1</property> 
    <property name="hibernate.c3p0.idle_test_period">0</property> 
    <property name="hibernate.c3p0.timeout">0</property>
    <property name="hibernate.c3p0.validate">true</property>

四。最不好的解决方案

使用Connector/J连接MySQL数据库,程序运行较长时间后就会报以下错误:

Communications link failure,The last packet successfully received from the server was * millisecond ago.The last packet successfully sent to the server was * millisecond ago。

其中错误还会提示你修改wait_timeout或是使用Connector/J的autoReconnect属性避免该错误。

后来查了一些资料,才发现遇到这个问题的人还真不少,大部分都是使用连接池方式时才会出现这个问题,短连接应该很难出现这个问题。这个问题的原因:

MySQL服务器默认的“wait_timeout”是28800秒即8小时,意味着如果一个连接的空闲时间超过8个小时,MySQL将自动断开该 连接,而连接池却认为该连接还是有效的(因为并未校验连接的有效性),当应用申请使用该连接时,就会导致上面的报错。

1.按照错误的提示,可以在JDBC URL中使用autoReconnect属性,实际测试时使用了autoReconnect=true& failOverReadOnly=false,不过并未起作用,使用的是5.1版本,可能真像网上所说的只对4之前的版本有效。

2.没办法,只能修改MySQL的参数了,wait_timeout最大为31536000即1年,在my.cnf中加入:

[mysqld]

wait_timeout=31536000

interactive_timeout=31536000 

重启生效,需要同时修改这两个参数。

  • 2
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: org.springframework.transaction.cannotcreatetransactionexception: 无法为打开JDBC连接创建事务 这个异常通常是由于数据库连接池中的连接数已经达到了最大值,无法再创建新的连接导致的。解决方法可以增加数据库连接池的最大连接数,或者检查是否有未关闭的连接导致连接池中的连接数一直增加。另外,也可能是数据库服务出现了问题,需要检查数据库服务是否正常运行。 ### 回答2: org.springframework.transaction.cannotcreatetransactionexception: could not open jdbc connection for 错误是Spring框架在执行数据库事务时发生的一种异常。通常情况下,这个错误出现是因为数据库连接无法被建立,也就是无法访问数据库。 如果出现这个错误,我们需要检查以下几个因素: 1. 数据库连接池配置是否正确:Spring框架使用连接池来管理数据库连接,如果连接池的配置不正确,将无法从连接池中获取到可用的连接。需要确保连接池的相关配置信息正确,例如数据库地址、端口号、用户名及密码等。 2. 数据库是否正在运行:在一些情况下,数据库本身出现问题导致无法正常运行。需要确保数据库正在运行,或者尝试重启数据库服务。 3. 网络连接是否畅通:如果数据库服务器和应用服务器不在同一台机器上,需要确保网络连接畅通。也可以尝试ping数据库服务器的IP地址,检查网络连接是否正常。 4. 数据库连接数是否达到上限:如果数据库连接数达到了上限,新的连接请求将无法得到响应。需要检查数据库连接数是否达到了上限,并根据需要调整连接池的相关配置信息。 总之,org.springframework.transaction.cannotcreatetransactionexception: could not open jdbc connection for错误出现的原因有很多种。需要结合具体情况进行排查,以便及时解决问题。 ### 回答3: 这个错误是由于在使用Spring事务管理的过程中,无法打开JDBC连接所导致的。需要对这个错误进行排查才能解决。 首先,考虑JDBC连接的配置是否出现了问题。我们需要检查数据库的配置,确保数据库的连接信息正确(例如:url、用户名、密码、数据库驱动等)。如果有配置不正确或者连接不上数据库,就会出现该错误。 其次,考虑数据库的连接池是否出现了问题。在使用连接池时,需要设置合理的最大连接数及其它参数,以保证程序正常运行。如果连接池设置不当,可能会导致连接池无法提供可用连接,引发事务异常。 第三,检查数据库的状态。可能是因为数据库服务器崩溃或者数据库连接被意外断开等因素导致的无法连接到数据库。这时我们需要检查数据库服务器的状态,以及网络情况,确保能够正常连接到数据库。 最后,可以考虑增加日志输出,观察具体的异常信息,以确定问题的原因并进行解决。同时也需要加强对事务的管理和安全原则,以提高程序的稳定性和安全性。 总之,对于事务异常问题,我们需要针对错误提示进行具体的排查和解决。只有挖掘问题的深层原因并加以处理,才能真正解决问题,避免其再次发生。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值