Reconnect policy with MySQL failing because of autoCommit error

Question

This related to this issue, but I didn't see any responses to it: Reconnecting a dead connection from a UnitOfWork commit - Autocommit error
I'm testing with MySQL 4.1 and I have a reconnect policy that does the following (I believe this is a pretty standard approach):
session.setExceptionHandler( new ExceptionHandler() {
public Object handleException(RuntimeException exception) {
     if (exception instanceof DatabaseException) {          
dbex.getAccessor().reestablishConnection(dbex.getSession());
However, when it reestablishes the connection (and I have traced this and can verify that this code is executing and a reconnect is performed), I get the following error for any updates:
Internal Exception: java.sql.SQLException: Can't call rollback when autocommit=trueError Code: 0
at oracle.toplink.exceptions.DatabaseException.sqlException(DatabaseException.java:277)
at oracle.toplink.internal.databaseaccess.DatabaseAccessor.basicRollbackTransaction(DatabaseAccessor.java:1090)
at oracle.toplink.internal.databaseaccess.DatasourceAccessor.rollbackTransaction(DatasourceAccessor.java:486)
at oracle.toplink.internal.databaseaccess.DatabaseAccessor.rollbackTransaction(DatabaseAccessor.java:1075)
at oracle.toplink.publicinterface.Session.basicRollbackTransaction(Session.java:377)
I only have this problem with the MySQL JDBC drivers. I can continue to read normally, but I can't perform any transactions.
This isn't so much of a question about MySQL specifically, but rather a question about how reestablishConnection() connects to the database differently from my initial login using DatabaseLogin. Obviously, I don't have this error connecting normally. I only get it after a reconnect is applied.
Specific questions are: Is there another handler I can add to ensure JDBC Connections returned by ServerSession are always setAutoCommit(false)? Am I reestablishing the JDBC connections incorrectly?
Nate

Answer 1

Nate,
This does appear to be MySQL JDBC specific but is most likely related to a general issue.
When the connection drops and you receive the notification through the exception handler I would typically recommend looking at the session in us (isUnitOfWork) or the query type (isWriteObjectQuery) to see if the operation that failed was involved in a transaction (UnitOfWork commit).
In these transaction cases you need to do more then just re-connect and retry. You need to ensure after reconnection that an application exception is raised so the UnitOfWork operation(s) can be retried completely. I would simply add to this case to ensure that the JDBC connection is put back in a state where it can be managed properly.
There is no special operation or any case I know of where any special auto-commit needs to be set on a connection after it has dropped and before it is re-connected.
Doug