Question

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

我的理解是Tomcat JDBC连接池不保证它为应用程序提供的连接的有效性。

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

Tomcat JDBC连接池提供了几种测试连接的选项。我发现更有趣的是testOnBorrow和testWhileIdle。

首先，我认为testOnBorrow是最佳选择，因为它在将连接提供给应用程序之前基本上验证了连接（最大频率由validationInterval定义）。

但是经过一秒钟后我才意识到在使用它之前测试连接可能会影响应用程序的响应能力。所以我虽然使用testWhileIdle可以更有效率，因为它在不使用时测试连接。

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

所以我最后问：我应该使用testOnBorrow还是testWhileIdle还是两者兼而有之？

另一方面，我很惊讶validationInterval不适用于testOnReturn而且我没有达到testOnConnect的目的。

Answer 1

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

大多数时候， testOnBorrow 风险最小，因为它确保（尽可能）在从池中返回连接以供您使用之前，已经进行了基本的健全性检查客户端和数据库服务器正在谈论条款。
它仍然不能阻止服务器连接的竞争状态下降，在“完整性检查”和＆amp;您的应用程序使用连接的时间。
但考虑到这是一个角落， testOnBorrow 给出了相当不错的保证。
现在需要权衡的是，每次请求连接时，都会对数据库服务器进行查询（无论重量有多轻）。这可能非常快，但成本仍然不是零。

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

另一方面，如果您的应用程序不是一成不变（就像大多数实际应用程序一样），那么拥有 testOnBorrow 选项是非常有益的。
在使用之前，它确保最大化，您有良好的连接。特别是考虑到失败的数据库操作的“无法轻松恢复”的成本（重试+手动干预+工作流程丢失等）。
现在假设你有 testOnIdle 选项。这需要您的连接在进行健全性检查之前空闲（取决于连接的空闲超时）。
这是对 testOnBorrow 的性能提升，但它有其自身的缺点。
- 真实世界的app-to-db-connections不仅仅是基于空闲超时的破坏，它们可以根据防火墙规则，n / w拥塞，数据库服务器进行维护/修补等而被删除。
- 因此，当您没有任何类型的“连接验证”时，它会返回到数据中观察到的连接错误数量的数据测量。
使用此选项时要注意的一件事是，当您使用最大连接并且您的应用程序运行良好时，您的池工作效果最佳，并且出于某种原因，如果您的数据库服务器重启或同样如此。现在所有的实时连接（从客户端的角度来看）都会出错，直到空闲超时开始。所以你的db-issue（这本来就是一场激烈的争斗）现在有点复杂，直到应用程序连接再次恢复正常或你重启应用程序。

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

Answer 2

只是为了让您知道，我刚刚对此进行了测试，并且可以同时使用testOnBorrow和testOnIdle属性。

但是，如上所述，我将选择testOnBorrow唯一的，因为我的应用程序没有大量流量，并且能够在握住它之前验证连接。

正如评论中所指出的，testOnBorrow不需要验证查询。如果您选择保留一个，则可以进行简单的选择：

jdbc.hive.testOnBorrow=true
jdbc.hive.validationQuery=SELECT 1

如果您想使用testWhileIdle，可以使用以下内容：

jdbc.testWhileIdle=true
jdbc.minEvictableIdleTimeMillis=1800000
jdbc.timeBetweenEvictionRunsMillis=1800000`