State of autoCommit after transaction

[Dinko Srkoč]

Hi,

While using `broker.transaction() { ... }` I noticed that, after committing/rollbacking the transaction, O/R Broker doesn't reset connection's `autoCommit` property to its initial value - the connection stays in non auto-commit mode. Is this a feature or a bug?

Such behaviour may cause problems if the code assumes and indeed expects connection to be in auto-commit mode after invoking Broker's `transaction`.

Interestingly, it seems that Apache Commons DBCP resets the connection's `autoCommit` property by itself after connection is returned to the pool. On the other hand, Tomcat's Connection Pool does not (naturally, we use the latter).

The workaround is, of course, to use `broker.transactional(conn) {...}` and provide own `autoCommit` handling. It would be nicer, though, to let this responsibility fall on O/R Broker.

Cheers,

Dinko

[Nils Kilden-Pedersen]

In my opinion, it's never the responsibility of a client to reset anything on a connection. In fact, the resource is considered dead once it's closed. It's only an implementation detail that connections are reused under the covers, and as such, it's the responsibility of the pool to make sure that connections are handed out in a consistent state.

It appears that Tomcat expects you to use JDBC Interceptors to configure/reset connection pool properties.

[Dinko Srkoč]

Hi Nils,

Thanks for the quick reply.

On Thursday, 15 December 2011 14:27:31 UTC+1, Nils wrote:

On Thu, Dec 15, 2011 at 6:14 AM, Dinko Srkoč <dinko...@gmail.com> wrote:

Hi,

While using `broker.transaction() { ... }` I noticed that, after committing/rollbacking the transaction, O/R Broker doesn't reset connection's `autoCommit` property to its initial value - the connection stays in non auto-commit mode. Is this a feature or a bug?

[...]

In my opinion, it's never the responsibility of a client to reset anything on a connection. In fact, the resource is considered dead once it's closed. It's only an implementation detail that connections are reused under the covers, and as such, it's the responsibility of the pool to make sure that connections are handed out in a consistent state.

It appears that Tomcat expects you to use JDBC Interceptors to configure/reset connection pool properties.

It seems that you are right.

From the Tomcat's ConnectionState api[1]: "... The ConnectionPool is optimized to do as little work as possible ... It relies on the application to remember how and when these settings have been applied. In the cases where the application code doesn't know or want to keep track of the state, this interceptor helps cache the state ..."

Thanks,

Dinko

[1]: http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/tomcat/jdbc/pool/interceptor/ConnectionState.html