在 JDBC 中，当 autocommit 为 false 且未设置显式保存点时，回滚是好风格还是浪费？

Question

假设你有以下代码：

Connection conn;
try
{
   conn = ... // get connection
   conn.setAutoCommit(false);

   ... // Do some modification queries and logic

   conn.commit()
} catch(SQLException e)
{
    conn.rollback() // Do we need this?
    conn.close()
}

在这段代码中，如果出现异常，是关闭连接（因为自动提交已关闭）还是显式回滚然后关闭连接更好？没有存档点。

我觉得添加回滚调用可能有意义，因为：

1) 将来有人可能会添加保存点但忘记添加回滚

2) 提高可读性

3) 它不应该花费任何东西，对吧？

但显然，这些都不是特别引人注目。有什么标准做法吗？

注意：我知道在关闭和回滚时需要重复尝试/捕获。我实际上有一个中间件可以抽象数据库访问并处理它，但我想知道添加它是否是多余的。

Answer 1

正常的成语如下：

public void executeSomeQuery() throws SQLException {
    try (Connection connection = dataSource.getConnection()) {
        connection.setAutoCommit(false);

        try (PreparedStatement statement = connection.prepareStatement(SOME_SQL)) {
            // Fire transactional queries here.

            connection.commit();
        } catch (SQLException e) {
            connection.rollback();
            throw e;
        }
    }
}

请注意，当 try 块完成时，Java 7 的 try-with-resources statement 总是在资源上隐式调用 close()，就好像它发生在 finally 中一样。

调用rollback() 在涉及池连接时也是强制性的。也就是说，它将重置连接的事务状态。池连接的close() 不会这样做，只有commit() 和rollback() 会这样做。不调用rollback() 可能会导致池连接的下一个租约仍将在其内存中保留上一个事务的（成功）查询。

另请参阅Connection#close() 的 javadoc（重点不是我的）：

强烈建议应用程序在调用 close 方法之前显式提交或回滚活动事务。如果调用close 方法并且存在活动事务，则结果是实现定义的。

Answer 2

关闭应该回滚，因为它不会在资源释放时提交，但最好让你的错误处理具体，所以如果你想回滚异常，就这样做。然后您可以在 finally{} 块中进行清理。 rollback() 仅在错误时发生，在这种情况下，您的 commit() 不成功，甚至没有达到。

Connection conn = null;
try {
    conn = ...

    ...
    conn.commit();
}
catch (SQLException e) {
    if (conn != null) {
        conn.rollback();
    }
}
finally {
    if (conn != null) {
        conn.close();
    }
}