c3p0存在严重bug

是不是你程序有什么地方 connection 没有 close 啊?

我以前用 Hibernate 的时候碰到过, 程序里直接使用了 native connection, 却没有在 finally 执行 close(), 不断的调用此方法, 当超过 c3p0 设置的 maxPoolSize(默认 15) 值时, c3p0 就会挂起, 等待数据库来关闭这些连接后再重新获取新的连接, 如果把程序里面的代码改好之后就没有问题了, 执行完 close 后 c3p0 会把连接又放回池中.

但是同样的问题, dbcp 却还在继续开启连接, 会一直到把数据库的最大连接撑没了才会被挂起(这个时候就要去数据库操作了).

c3p0 在测试的时候出现, 可以潜在的消除因为程序不当而引起的 bug, 改过来后就好了. c3p0 其实不错.

当然, 你这个用的 JdbcTemplate 我没试过. 不敢妄言.

40并发这样基本的性能测试都不过，这样的程序可能嘛？
感觉楼主分析的问题不透彻啊，你这样的分析都是猜测，你这样分析问题只能越分析越乱啊，把你的c3p0的jar包发一下，然后把你的程序配置文件发一下，还有程序代码发一下，这样才能找到错误的原因。

楼主的数据和应用服务器之间是不是存在防火墙？

我遇到过防火墙配置不正确导致报同样的错误。

Some highlights:

+ Some JDBC drivers freeze up if cached Statements are close()ed while their parent
  Connections are in use. Previously users of these drivers (Oracle, JTDS) generally
  had to forego Statement caching to avoid deadlocks. C3P0's statement cache can now
  be set to cautiously close Statements only when the parent Connections are known
  to be idle. If you experience "APPARENT DEADLOCKS" due to StatementCloseTasks, set

      c3p0.statementCacheNumDeferredCloseThreads=1

下最新版本：c3p0-0.9.2-pre1.jar

官方文档是这样描述的，设置这个线程 用于回收没用的连接池，


statementCacheNumDeferredCloseThreads
Default: 0
If set to a value greater than 0, the statement cache will track when Connections are in use, and only destroy Statements when their parent Connections are not otherwise in use. Although closing of a Statement while the parent Connection is in use is formally within spec, some databases and/or JDBC drivers, most notably Oracle, do not handle the case well and freeze, leading to deadlocks. Setting this parameter to a positive value should eliminate the issue. This parameter should only be set if you observe that attempts by c3p0 to close() cached statements freeze (usually you'll see APPARENT DEADLOCKS in your logs). If set, this parameter should almost always be set to 1. Usually, if you need more than one Thread dedicated solely to destroying cached Statements, you should set maxStatements and/or maxStatementsPerConnection so that you don't churn through Statements so quickly

我也困扰很久，明天用这个参数也试一下，希望能够解决，
出现这个问题，一般只针对oracle数据库

哪里配置有问题吧，我们经过压力测试，1K以上的并发量都没有问题

某c3p0版本  大家都知道这问题...

我们也改用proxool了

这种问题估计让LZ纠结了很久啊，不过每次解决一个这样的难题，那叫一个成就感十足啊，哈哈

果断proxool。

没问题吧，项目上也用的c3p0,也报过你那个错，后来发现有一处connection没有close.