锁表后,线程池与连接池的问题

一直以来对连接池与线程池的运作不清楚。
我参与的一个项目中存在一种情况,有一个业务在应用中存在并发的修改一张表的某个统计数据,那么如果程序或者其他事务原因,造成该数据出现行锁。

我的问题是:在容器(websphere)设置的连接超时时间前,是否 所有操作该业务的请求都将等待并占用一个数据库连接池的资源和一个线程,随着请求的不段增加,从而造成服务器宕机,数据库连接池的资源耗尽!
因为现成出现了服务器宕机,并且日志显示超时了:SRVE0133E: java.net.SocketTimeoutException: Async operation timed out

3个回答

连接池和线程池是有本质区别的,当然也有相识的地方,打个比方吧:
连接池就好比一栋大楼所有电梯这样的一个集合;一台电梯好比连接池中一个连接。如果有人乘一台电梯上去,就不能为你服务,你只有选择其他空闲的电梯,或者你等待这个电梯服务完。连接池重要的是根据不同的应用要求配置参数可能完全不一样,比如,连接的超时时间,空闲回收时间,多久测试一次连接可用性(由于各种原因有时候连接空闲,但是无效,就好比电梯没有被其他人使用,你可以使用,但是没电),连接池中连接最大数,最小数等
线程池和连接池的配置大部分一样,因为原理很相似;但是又本质的区别:
连接池:
里面是数据库连接
线程池:
里面是线程
面向解决问题方向不一样:一个是减少数据库系统开销,提高数据库的实效,更多的为应用程序服务;另一个是,提高系统的处理能力和服务量。一个面向数据库连接资源,一个面向cpu资源
他们的的目的大致相同:提高系统的可靠性、充分利用资源

你的问题,两方面入手,一方面:数据库连接数稍微多一点,连接超时时长短一点;另一方面:线程数少一点,短事务,线程间适时让线程让出cpu(事务的前后,不要事务开启中间)。
如果想彻底解决,系统架构就要改变,不要操作公共资源

初步判断:
连接数用尽是因为资源竞争造成数据库锁,连接没有及时释放,所以连接数不断增长,直到用尽。

iteye_6401
iteye_6401 最近我也遇到过类似的问题,应该是连接池参数的配置问题。
7 年多之前 回复
iteye_6401
iteye_6401 一个连接由于数据库锁阻塞,还未到超时时间,第二个的请求接踵而至,到只占用了两个连接,依次类推,如果并发数较大,应该很快就会把连接数占满。 请求过来,连接池肯定要马上分配连接,肯定不会等待,如果等待就谈不上连接池的性能了。
7 年多之前 回复
zouwei2008
zouwei2008 达到超时时间后,为什么这个连接不自动释放呢,而是就这么一直增加,直到用尽数据库连接资源,服务宕机。还有,连接不断增长,为什么不能等待呢,等待连接资源释放,而是服务器宕掉呢?
7 年多之前 回复

是的。操做系统的人发现系统反应慢,肯定会重复操作。锁表后,链接资源不释放,造成服务器负载上升。

Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
立即提问