池式连接超时怎么解决

池式连接超时的解决方法：

1、修改几个关键页面或访问比较频繁的数据库访问 *** 作，使用DataAdapter和DataSet来获取数据库数据，不要使用DataReader。

2、在访问数据库的页面上使用数据缓存，如果页面的数据不是经常更新（几分钟更新一次）的话，使用Cache对象可以不用访问数据库而使用缓存中的内容，那么可以大大减少连接数量。

3、修改代码，把使用Connection对象的地方都在Close()后面加上Dispose()调用。

池式连接超时的原因

系统割接后，中间件和数据库进行了防火墙隔离，由于数据库和应用都进行了割接，系统架构由原先的单一网络变成了跨系统部署，数据库和应用之间的访问通过防火墙；而防火墙这边对空闲的连接配置了超时时间（一般默认为30分钟），一旦超过时间，会自动将连接断掉。

而断掉后，应用程序这一侧的数据库连接池这边还是认为该连接有效，它只在应用获取该连接时才会进行一个有效性测试，会每间隔一个时间尝试一次，尝试n次后才确定该连接失效，发起重连，最终造成业务耗时长。

由于连接池连接数很多，势必造成有部分连接空闲时间超过了防火墙的设置，而应用程序这边没有配置对空闲连接的维护参数，空闲连接会一直认为有效，所以该现象只会出现在连接池中的空闲连接上；当应用获取已被防火墙断开的空闲连接时，就会造成应用的响应慢，或者直接提示connection timed out异常。

您好，发现了问题，我首先在c3p0上加上 调试信息的配置 ：

c3p0debugUnreturnedConnectionStackTraces=true

c3p0unreturnedConnectionTimeout=90 （我的连接超时时间是60s，所以这设置了90s）

applicationContext数据源配置增加响应配置

<property name="breakAfterAcquireFailure" value="${c3p0breakAfterAcquireFailure}" />

<property name="testConnectionOnCheckout" value="${c3p0testConnectionOnCheckout}" />

果然发现很多未回收的连接，正常情况下超时未回收的连接会有一些，但是不会这么多啊。

经查资料在hibernate sessionFacory中增加配置（>

执行了错误的sql。

问题就出在druid连接池上，连接池在执行完了某一条错误的sql以后，报错信息会被保存在执行sql的线程中，当下一条拿到这个线程的sql执行时，就直接报错，而不会去执行sql。

最终的解决方法就是解决那条问题线程，肯定是哪里出错才会保留报错信息，或者升级druid的版本。

吃了顿饭回来，忽然想到自己都没有在数据库里面创建一个要连接的database，所以才导致这个错误，

果断创建数据库，启动项目，OK，问题解决，

有时候真的是需要一些灵感,,,,

以上就是关于池式连接超时怎么解决全部的内容，包括:池式连接超时怎么解决、SS2H + c3p0连接池 程序在运行一段时间后 就会出现无法连接数据库的错误、在使用druid数据库连接池执行后为啥会出现出现无效的源发行版14等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！