A.40. 验证时间方法比较

比较方面

validate-on-match 方法

background-validation 方法

可靠性

使用每个数据库连接前， validate-on-match 方法立即验证。这意味着，执行验证来测试从池中签出供应用使用的连接。

background-validation 方法不太可靠，因为连接可能会在定期后台验证和验证连接相关的时间之间失败。

当后台验证方法频繁运行时，仅针对池中的那些连接执行验证，这些验证不会被应用保留给使用。这也意味着不会执行任何验证来测试从池中签出的连接以供使用。

性能取决于系统、网络性能以及任何连接问题的时间和范围

在使用 validate-on-match 请求连接时，保持闲置长时间的系统用户更有可能看到短暂或更长的延迟。

具有效率更高验证机制的系统用户，如 JDBC 4 验证机制，在使用 validate-on-match 时可能会注意到较少的延迟。如果系统很少闲置且连接不太可能超时，则这是 true。

在影响池中大多数或所有连接的大量中断后，使用 validate-on-match 配置的数据源用户更有可能在获取连接时遇到延迟。这是因为，在用户等待连接时，损坏的连接会被迭代验证和被驱除。

在使用 background-validation 请求连接时，保持闲置长时间的系统用户不太可能看到短暂或更长的延迟。

具有效率更高验证机制的系统用户（如 JDBC 4 验证机制）在使用 background-validation 时可能会注意到较少的延迟。如果系统很少闲置且连接不太可能超时，则这是 true。

在影响池中大多数或所有连接的大量中断后，配置了 后台验证 的数据源用户更有可能遇到需要多次返回并重新尝试的连接。

容错的编码

如果出现任何错误，应用程序逻辑在使用 validate-on-match 时仍然保持不变，因为即使应用从池中获取连接，连接也可能是外部终止。

使用 validate-on-match 时，损坏的连接不太可能存在。这是因为 validate-on-match 会在使用前立即对连接执行验证。

如果出现任何错误，应用程序逻辑在使用 background-validation 时保持不变，因为即使应用从池中获取了连接，连接可以在任何点上终止。

使用 后台验证时，损坏的连接可能会存在。