Tomcat JDBC 连接池：testOnBorrow 与 testWhileIdle

由于各种原因，池中的连接可能会变得无效：服务器连接超时、网络问题......

我的理解是，Tomcat JDBC 连接池不对其向应用程序提供的连接的有效性提供任何保证。

为了防止（实际上只是降低风险）从池中获取无效连接，解决方案似乎是配置连接验证。验证连接意味着在数据库上运行一个非常基本的查询（例如SELECT 1;在 MySQL 上）。

Tomcat JDBC 连接池提供了多种测试连接的选项。我觉得比较有趣的两个是testOnBorrow and testWhileIdle.

首先我在想testOnBorrow是最好的选择，因为它基本上在将连接提供给应用程序之前验证连接（最大频率由validationInterval).

但过了一会儿，我意识到在使用之前测试连接可能会影响应用程序的响应能力。所以我认为使用testWhileIdle可以更有效，因为它可以在不使用连接时测试连接。

无论我选择哪个选项，它们似乎都只会降低获得无效连接的风险，但这种风险仍然存在。

所以我最后问：我应该使用testOnBorrow or testWhileIdle或者两者的混合？

顺便说一句，我很惊讶validationInterval不适用于testOnReturn我真的不明白这样做的目的testOnConnect.

这个问题没有 100% 正确的答案。这是一个权衡和背景的问题。

• 大部分的时间，借用测试风险最小，因为它确保（尽可能）在从池中返回连接供您使用之前，已进行基本的健全性检查以确保客户端和数据库服务器处于正常状态。
• 它仍然无法阻止在进行“健全性检查”的时间和应用程序使用连接的时间之间服务器连接的竞争条件下降。

• 但考虑到这是一个极端情况，借用测试提供了很好的保证。

• 现在的权衡是，每次请求连接时，都会对数据库服务器进行查询（无论多么轻量级）。这也许很快，但成本仍然不为零。

如果您有一个繁忙的应用程序，并且具有非常好的数据库连接可靠性，那么您将从数据中开始看到，“对池中每个连接请求进行有效性检查”的成本超过了检测连接问题的好处。

• 另一方面，如果您的应用程序并不总是繁忙（像大多数现实世界的应用程序一样），那么拥有借用测试选项。

• 它最大限度地确保您在使用之前拥有良好的连接。特别是考虑到从失败的数据库操作中“无法轻松恢复”的成本（重试+手动干预+工作流程损失等）。

• 现在想象一下如果你有空闲测试选项。这要求您的连接在进行健全性检查之前处于空闲状态（取决于连接的空闲超时）。

• This is a performance improvement over testOnBorrow but it comes with its own disadvantages.
  • 现实世界中的应用程序到数据库的连接不仅仅是基于空闲超时的破坏，它们还可以根据防火墙规则、网络拥塞、数据库服务器正在进行维护/修补等而被删除。
  • 因此，当您没有任何类型的“连接验证”时，它又回到了数据测量，即在数据中观察到了多少连接错误。
• 使用此选项需要注意的一件事是，当您的池在最大连接数下工作得最好并且您的应用程序性能良好时，并且由于某种原因您的数据库服务器经历了重新启动或类似情况。所有实时连接（从客户端角度来看）现在大部分都会出错，直到空闲超时开始。因此，您的数据库问题（这本来是一场交火）现在变得有点复杂，直到应用程序连接再次恢复正常或者您也重新启动应用程序。

最后一个数据点是，对于某些应用程序，关键路径不是“验证查询”时间（希望以较低的毫秒为单位）。应用程序有更大的问题需要处理。当然，对于某些应用程序来说，这段时间非常重要。