c3p0连接池，未对入住或退房进行测试 [英] c3p0 connection pool without testing on either check-in or check-out

问题描述

来自c3p0 文档:

对于某些应用程序，高性能比偶尔出现数据库异常的风险.默认情况下配置，c3p0根本不进行任何连接测试.设置一个相当长的 idleConnectionTestPeriod ，并且不在结帐时进行测试签到根本是一种出色的高性能方法.

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 ，那么将不会测试这些连接的有效性，并且所有使用它们的尝试均将失败.基本上，连接池不会自动从数据库不可用中恢复.

If I understand the meaning of the c3p0 configuration properties correctly, if the database becomes unavailable for a short period of time and then recovers (e.g. it is restarted or a network issue appears), and if there is a fairly high usage of the connections which are pooled in the c3p0 so that no connection is idle longer than idleConnectionTestPeriod, then none of those connections would ever be tested for validity and all attempts to use them would be unsuccessful. Basically, the connection pool would not automatically recover from the db unavailability.

文档中的措辞是否很糟糕，说明此是一种出色的高性能方法，而没有警告连接池失去了从无效连接中自动恢复的能力，或者我已经误解了相关配置属性的含义?

Is it just bad wording in the documentation stating that this is an excellent, high-performance approach without a warning that the connection pool loses the ability to auto-recover from invalid connections, or I have misunderstood the meaning of the relevant configuration properties?

推荐答案

呵呵.我写的大概是十多年前的，您是对的，这不是一个好建议.最初，c3p0中的连接测试通常非常昂贵(由于dbms/驱动程序的独立性和完全有效性测试的确定性，它使用了昂贵的元数据getTables(...)测试)，我强烈建议人们确保异步进行测试，在签入和空闲测试中.一旦 preferredTestQuery 和jdbc4 Connection.isValid()使高效可靠的测试成为可能，我就对文档进行了修订，以消除对同步检查的阻碍.但这显然没有改变，即使在过去，这也是一个不好的建议.在实践中，如果您不在结帐期间进行测试，则建议同时对checkin 和空闲测试进行异步测试，并建议通常使用中度频繁的空闲测试(大约30秒)，以减少应用程序看似过时的可能性连接以及中断后刷新连接之前的延迟.

Huh. I wrote that, probably more than a decade ago, and you are right, it isn't good advice. Originally, Connection testing in c3p0 was often very expensive (because for dbms/driver independence and certainty of a full validity test, it used an expensive metadata getTables(...) test), and I strongly advised people to make sure to test asynchronously, in checkins and idle tests. Once preferredTestQuery and then jdbc4 Connection.isValid() made efficient reliable testing possible, I revised the docs to remove the discouragement of synchronous checks. But apparently this stayed, and it is bad advice even for the old days. In practice, if you are not testing during checkout, I recommend both async tests on checkin and idle tests, and moderately frequent idle tests (30 seconds-ish) usually, to reduce the likelihood an application sees stale Connections and the delay before Connections get refreshed after an outage.

我将对此进行修订.谢谢.

I'll revise this going forward. Thanks for the catch.

这篇关于c3p0连接池，未对入住或退房进行测试的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！