来自 c3p0 documentation :
For some applications, high performance is more important than the risk of an occasional database exception. In its default configuration, c3p0 does no Connection testing at all. Setting a fairly long
idleConnectionTestPeriod
, and not testing on checkout and check-in at all is an excellent, high-performance approach.
如果我正确理解c3p0配置属性的含义,如果数据库短时间不可用然后恢复(例如重新启动或出现网络问题),并且如果使用率相当高在 c3p0 中汇集的连接,因此没有连接的空闲时间超过 idleConnectionTestPeriod
,那么这些连接都不会被测试有效性,并且所有使用它们的尝试都会失败。基本上,连接池不会从数据库不可用中自动恢复。
是不是文档中的错误措辞表明此是一种出色的高性能方法,却没有警告连接池失去从无效连接中自动恢复的能力,或者我有误解了相关配置属性的含义?
最佳答案
嗯。我写的,大概十多年前,你是对的,这不是好建议。最初,c3p0 中的连接测试通常非常昂贵(因为对于 dbms/driver 独立性和完整有效性测试的确定性,它使用昂贵的元数据 getTables(...) 测试),我强烈建议人们确保进行异步测试,在 checkin 和空闲测试中。一旦 preferredTestQuery
和 jdbc4 Connection.isValid() 使高效可靠的测试成为可能,我修改了文档以消除同步检查的阻碍。但显然这仍然存在,即使在过去,这也是一个糟糕的建议。在实践中,如果您不在结帐期间进行测试,我建议对 checkin 和 空闲测试进行异步测试,并通常适度频繁地进行空闲测试(30 秒左右),以降低应用程序看到陈旧的可能性中断后连接和连接刷新之前的延迟。
以后我会修改这个。感谢您的关注。
关于java - c3p0 连接池,无需在 checkin 或 checkout 时进行测试,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/44807078/