IT运维笔记


c3p0 Deadlock原因分析

1.数据库服务没有启动 以上出现的错误就是我在关闭了自己机器上的mysqld后亲测的一个错误,我的机器上的mysql服务器是默认开启的,但是由于将jar包给同时后,他的机器上其实是没有mysql的,所以会出现错误 2.没有创建对应数据库 在mysqld开启的情况下,没有对应数据库的情况下也是会出现这样的问题的 3.就涉及到c3p0连接池的配置文件了 由于我遇到的不是这个问题,所以只能在网上参照一些配置方面出问题的原因,关于配置出错的问题众说纷纭,具体以自己的项目出错为准 ①maxStatements 和checkoutTimeout 原因:I'm surprised that no other theories or options have come out... Is there really no way to deal with the cached statement warnings other than to completely disable prepared statement caching? If so, that reduces the value of c3p0 to connection pool only. 这段话我是从hibernate论坛中截取出来的,大致意思就是c3p0在同时关闭statment和connection的同时,由于他们关闭的时间有一个很短的间隔,但是在这个时间段内,connection并没有被关闭,导致了有一些perparedstatment还处于缓存当中 另外,从我参考的文章来看,他是在做压力测试时1小时候才出现的问题,所以如果本身上来说的话,没有一次性做大量的连接数据库的操作的话,应该是不会出现这样的问题的 ②maxPoolSize和initialPoolSize 在这篇文章中,他把值都设置成了1,给出的解释是: 因为数据库的连接数是有限的,每次应用启动C3p0都会占用数据库的连接来填充C3p0的连接池,而当数据库的资源被占光时就会因为无法获得共享资源而报死锁。仅仅摘录,遇到问题的童鞋们不妨试一试 ③更新c3p0的包 有可能是c3p0的包版本过旧造成的,版本低的c3p0包会导致获取连接的时间过长而在获取新的连接时造成死锁,具体参考的是stackoverflow中别人提出的一个问题 The tasks that are dealocking are Connection acquisition tasks. That is, c3p0 is trying to acquire new Connections from your database, and those Connection acquisition attempts are taking a long time. The first thing I would do is upgrade to 0.9.2.1, which has a much improved means of performing a round of Connection acquisitions in situations where acquisition attempts sometimes fail. If that doesn't solve your problem, then you'll need to figure out why c3p0's attempts to acquire a Connection are hanging for long periods of time: neither succeeding nor failing with an Exception.