JTA setRollbackOnly() w/ JDBC getConnection()

Question

I don't know if this belongs in the JTA forum or the JDBC forum, so please let me know if this is in the wrong place.
The enlistResource() method in JTA will throw a RollbackException when trying to enlist a resource after setRollbackOnly() is called. Should the JDBC driver or connection pool pass this exception to the user?
What I am seeing, in a certain implementation of a connection pool, is getConnection() throwing a SQLException when the enlistResource() throws RollbackException. I would expect the pool to handle the RollbackException and still return a connection, but I could be wrong.
It makes sense to me that the transaction manager should still allow resources to be enlisted even if the TX status is STATUS_MARKED_ROLLBACK. If the TM should allow enlistment then I see no reason why the pool shouldn't return a connection instead of throwing a SQLException.
Can anyone confirm this for me, or shed some light on the topic?
-Andy

Answer 1

Hi,
The rollback exception can happen outside the responsibility of the JTA transaction manager (namely in the underlying JDBC database). It indicates that the database has decided to time out, for instance.
The only way that both the JTA and the connection pool can find out in that case is by a failure such as this one.
The only (well, straightforward) way to hide this would be to re-submit all previous work to the JDBC data source but in a NEW series of interactions through a new connection. This would require that the connection pool be aware of application-level logic and caches it in the transaction. In addition, since resubmission of previous SQL statements may yield different results the second time, it would jeopardize transactional correctness (serializability) of work done in other data sources.
So, in a nutshell: the current situation is the most practical one (but maybe not for the end-user).
Hope that helps,
Guy
http://www.atomikos.com