HikariCP 如何处理不完整的 JDBC 事务？答案

【问题标题】：How does HikariCP handle incomplete JDBC transactions?HikariCP 如何处理不完整的 JDBC 事务？
【发布时间】：2014-01-13 12:55:49
【问题描述】：

昨天偶遇HikariCP，花了一晚上的时间研究。我对fine tuning 的实现和设计所付出的大量细节和努力印象深刻。直截了当，我无法确定它如何实际处理那些被检查回池的连接，它们的autoCommit 设置为false，而commit() 和rollback() 都没有在它们上发出，例如，由于异常。对于下一个请求者来说，这可能是许多严重事务问题的根源，他们期望一个新的连接，但不幸地收到了这个带有悬空事务状态的连接。

虽然 C3P0 和 Tomcat 的 JDBC 池为此目的（通过配置或拦截）有一些所谓的 Knobs，但我在 HikariCP 的文档或支持组中找不到任何内容。如果我错了，请纠正我，但是编写一个简单的单元测试表明池对此没有任何作用。

我需要知道这个观察是否真的正确，并且我没有遗漏任何信息。另外，如果有任何计划在 HikariCP 中解决这个问题，因为这对我来说很重要。

谢谢。

【问题讨论】：

在github上问作者更有可能得到答案。

标签： java jdbc transactions connection-pooling hikaricp

【解决方案1】：

我是 HikariCP 的作者之一。如果关闭自动提交，HikariCP 不会自动执行提交或回滚。通常期望显式关闭自动提交的应用程序准备好正确处理这些问题（在finally 块中推荐）- 就像官方 JDBC 文档中的this example 一样。

如果连接返回到池且自动提交设置为 false，我们愿意为 HikariCP 添加自动“回滚”行为（但不是自动“提交”）。如果您希望这种行为，请打开功能请求。

更新：HikariCP 1.2.2 及更高版本对关闭的连接执行自动“回滚”，并将自动提交设置为“false”。此外，它会将事务隔离级别重置为配置的默认值，并且如下面的 cmets 所述，当然会关闭打开的语句等。

更新：HikariCP 2.3.x 及更高版本现在在自动提交设置为false 时额外跟踪事务状态，如果事务状态为干净，将绕过自动回滚操作。

【讨论】：

是的，自动回滚会很好，因为它在这种情况下最有意义。我同意你的看法，应用程序首先不应该让连接处于这种状态，但是由于我在我的项目中处理高度模块化的框架，我无法完全控制我的程序员，这很容易滑倒这种方式或其他方式。我将为此打开一个功能请求。感谢您的及时回复。
关闭逻辑连接时的连接池应该 1) 提交或回滚连接，以及 2) 关闭任何依赖对象（语句、结果集等）。由连接池分发的（逻辑）连接在所有方面都应该像正常（非池化）连接一样表现（当然，基础物理连接没有关闭）。
@HamidNazari 我不同意，尽管应用程序当然应该“表现良好”，但从连接池中检索到的连接的用户应该能够像使用普通连接一样使用它（JDBC 4.1，第 11.1 节：“连接池对客户端是完全透明的：客户端获取池连接并以与获取和使用非池连接相同的方式使用它。”）
@MarkRotteveel 我明白你的意思，但我认为在处理超过 100 万行活动代码的项目时，严格成为必要条件。在这些领域中，“表现良好”编码的主观概念开始变得越来越重要。这就是为什么我认为客户不应该违反一个基本的经验法则，即以有意义的方式释放他们获得的宝贵资源。
@HamidNazari 我的观点是：即使连接池的一个“客户端”行为不端，该连接池的其他客户端也不应该遭受这种后果。一个不遵循 JDBC 标准建立的规则的连接池（从池中获得的连接应该表现得像一个普通的连接），就像 HikariCP 显然所做的那样，会产生奇怪且难以跟踪的错误，