rollback dirty connections on close #116
Description
This issue documents how ebean-datasource behaves when closing the connection without committing or rolling it back.
The JDBC-API clearly mentions, that 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.
Some drivers, such as DB2, enforce this recommendation and will throw an exception if close is called without a commit or rollback.
Not committing data before returning the connection to the pool can lead to unexpected bugs. For example, consider the following code snippet:
To understand, take a look at this code:
try (Connection conn = pool.getConnection()) {
conn.createStatement().execute("update mytable set x = 42");
// note the missing commit here
}In this code, an update statement is executed on the connection but not committed before the connection is returned to the pool.
Possible consequences include:
- The connection may be trimmed by the pool and close is called -> DB2 driver will not allow this
- The connection may be reused by another code that commits or rolls back the connection before returning it to the pool -> the update statement above will be committed (or rolled back) by a completely other place in your code.
To prevent such issues, the ebean-datasource by default performs a rollback if commit or rollback is forgotten in the code (except for readonly or autocommit connections). This situation is loged as a warning with the relevant stack trace, as it is often a critical programming error.
To easily identify such error-prone code in your application, you can enable datasource.xxx.enforceCleanClose=true in your tests. This will cause ebean-datasource to throw an AssertionError if a commit or rollback is forgotten.
See PR #107 for more information.