连接池 - 为什么在签入时测试连接？

Question

您好，这个问题应该适用于比 c3p0 更多的连接池管理器，但我会以那个为例。

c3p0 为连接池管理提供的一个选项是在连接被检入连接池之前对其进行测试。 这是否意味着在应用程序使用了连接之后？如果是这样，如果它只是被应用程序使用，连接不是总是有效的吗？

除非我的理解是错误的，否则这似乎是检查连接是否有效的无用时间，因为无效的连接会在应用程序尝试使用它时引发异常。

更新： 我要问的真正问题是，刚刚在应用程序中失败的陈旧连接是否仍会被检查回池中以最终一次又一次地失败？如果答案是否定的，那么签入测试将毫无意义，因为“爆炸”连接永远不会被发送回池。多年来，我一直在使用 c3p0 和 testOnCheckIn 和测试查询间隔，但实际上并没有深入了解原因。

Answer 1

在结帐时测试连接是否是一个性能问题，很大程度上取决于测试的效率，以及结帐时连接的工作量。正如您所说，配置连接测试的最安全、最简单的方法是在结帐时进行测试。但这也意味着客户端必须经历测试的延迟。

如果您希望异步测试连接，即在客户端代码路径之外，那么您希望在签入时测试连接，并在签入连接时定期测试。基本上，策略是为了确保池中空闲的Connections不太可能无效，这样您就可以安全地检查它们而无需测试。 （“安全”当然是程度问题。即使在结帐时测试，连接也可能在测试和第一次客户端使用之间失效。）

假设连接在签入时有效不是一个好主意，因为客户端刚刚使用它。首先，客户端遇到异常这一事实并不一定会向池发出连接无效的信号。例如，对Connection.commit() 的调用可能会因为事务中的行的并发修改而失败，即使连接完全有效。从根本上说，签出连接时遇到的异常是客户的业务，而不是池的业务。 c3p0（我认为不寻常）确实注意到客户端遇到的异常，并触发静默连接测试，以便池可以推断连接有效性。但是客户端可能会遇到来自有效连接的异常的原因有很多。

其次，池不能依赖于客户端最后一次使用连接后的及时签入。这是一个坏主意，但客户端通常将连接打开的时间比他们实际的数据库工作时间长得多。 las 客户端使用和签入之间的任何时间窗口显然都是连接可能出错的窗口。

因此，如果您想要异步连接测试 - 即（对于足够大的池）对客户端延迟没有贡献的连接测试 - 您需要在签入时进行测试，然后在连接被池化和空闲时进行频繁测试.

所有这一切都表明，实际上，异步连接测试的需求已经减少，因为 JDBC 驱动程序现在通过Connection.isValid() 提供快速、可靠的测试。曾几何时，为了定义独立于 DBMS 的可靠连接测试，c3p0 不得不默认对数据库元数据进行通常非常缓慢的查询。此测试的延迟可能会对客户端性能造成真正的影响。使用Connection.isValid()（或高效的preferredTestQuery），测试通常足够快，以至于结账时测试的简单性和稳健性超过了对小客户端延迟的影响。 c3p0 文档用于建议出于性能原因使用异步连接测试。 current documentation 建议首先在结帐时进行同步测试，仅当测试延迟影响性能时才退回到异步测试作为潜在的优化。在大多数情况下，实际上，您现在通常只使用testConnectionsOnCheckout。

Answer 2

这是否意味着在应用程序使用了连接之后？

是的

如果是这样，如果它只是被应用程序使用，连接不是总是有效的吗？

如果您的应用使用了连接，但它似乎已损坏，因此引发了异常，该怎么办？在这种情况下，如果您只是将其放回池中，它将再次返回，并且另一个请求将失败。一段时间后，更多的连接可能会中断，失败请求的比例会增加。

有些人倾向于在签入后进行测试的原因是他们害怕签出测试对性能的影响。您的请求必须等到进行涉及网络流量的 SQL 查询。这可能或不可能对您的应用程序造成真正的危害。

我个人没有做过任何性能测试，也不知道这个问题有多严重，但这也取决于您对应用的预期延迟水平。您还可以依赖@Steve Waldman 指出的连接的异步测试 - 这样您就可以在请求处理线程之外测试您的连接。