Say you have the following code:
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() }
In this code, if there is an exception, is it better style to just close the connection (since autocommit is off), or to explicitly roll back and then close the connection? There are no save points.
I feel that it might make sense to add the rollback call because:
1) Someone, in the future, might add save points but forget to add the rollback
2) It improves readability
3) It shouldn't cost anything, right ?
But obviously, none of these is particularly compelling. Any standard practice?
Note: I'm aware of the need to do a repeat try/catch on closing and rollback. I actually have a middleware that abstracts the database access and takes care of that, but I was wondering whether adding it was superfluous.
When the autocommit mode is false, the JDBC driver will implicitly start a new transaction after each commit. If this method is called during a transaction, the transaction is committed.
You should set autocommit to true whenever you're issuing database transactions. A database trasaction is a logical unit of work, which usually consists of multiple database operations (usually multiple updates) and you want either all of them to succeed or all of them to fail.
setAutoCommit(false); Following JDBC program establishes a connection with the database and turns off the auto-commit.
To enable manual- transaction support instead of the auto-commit mode that the JDBC driver uses by default, use the Connection object's setAutoCommit() method. If you pass a boolean false to setAutoCommit( ), you turn off auto-commit.
The normal idiom is the following:
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; } } }
Note that Java 7's try-with-resources statement always implicitly calls close()
on the resource when the try
block finishes, as if it happens in finally
.
Calling rollback()
is also mandatory when it concerns a pooled connection. Namely, it will reset the transactional state of the connection. The close()
of a pooled connection won't do that, only the commit()
and rollback()
will do that. Not calling rollback()
may lead that the next lease of the pooled connection will still have the (successful) queries of the previous transaction in its memory.
See also javadoc of Connection#close()
(emphasis not mine):
It is strongly recommended that an application explicitly commits or rolls back an active transaction prior to calling the
close
method. If theclose
method is called and there is an active transaction, the results are implementation-defined.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With