java - 在 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;
        }
    }
}

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

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

参见 Connection#close() 的 javadoc (重点不是我的):

It is strongly recommended that an application explicitly commits or rolls back an active transaction prior to calling the close method. If the close method is called and there is an active transaction, the results are implementation-defined.