Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.1.9, 2.2.0-rc-3
-
None
Description
If checked exception is thrown in the Sql#withTransaction(Closure) code block, the transaction will not be rolled back. Rollback is still invoked for runtime exceptions, SQLException, and Error - exceptions that are explicitly handled by withTransaction.
The following code illustrates the behaviour:
def sql = groovy.sql.Sql.newInstance(...) try { sql.withTransaction { sql.execute "CREATE TABLE foo_table (col1 INTEGER)" sql.execute "INSERT INTO foo_table (col1) VALUES (42)" throw new Exception("will not cause rollback") } } catch (e) { assert e.message == "will not cause rollback" assert sql.firstRow("SELECT COUNT(*) n FROM foo_table").n == 1 sql.execute "DROP TABLE foo_table" // clean-up by hand }
Expected (but undesirable) outcome is that transaction is not rolled back - table foo_table still exists in the catch block with one inserted row.
In Groovy 2.0.x and earlier, checked exceptions would indeed cause rollback. The above code would fail on the first assertion, attempting to read from a non-existing table.
Exception handling code in withTransaction basically hasn't changed between 2.0 and 2.1, yet the method exhibits different behaviour.