Atomikos Forum

This code-block swallows the original exception making it impossible to write custom exception-handlers to deal with the original cause (unique-key violation etc.):

TransactionStateHandler:275 (atomikos-3.7.0)


275: while ( enumm.hasMoreElements () ) {
276:     sync = (Synchronization) enumm.nextElement ();
277:     try {
278:         sync.beforeCompletion ();
279:     } catch ( RuntimeException error ) {
280:         //see case 24246: rollback only
281:         setRollbackOnly();
282:         Configuration.logWarning ( "Unexpected error in beforeCompletion: " , error );
283:     }
284: }
285:
286: if ( ct_.getState().equals ( TxState.MARKED_ABORT ) ) {
287:     //happens if synchronization has called setRollbackOnly
288:     //-> rollback and throw error
289:     rollback();
290:     throw new RollbackException ( "The transaction was set to rollback only" );
291: }

The RuntimeException "error" on 279 should be book-keeped and included in the RollbackException on line 290, like this:


Throwable cause = null;
while ( enumm.hasMoreElements () ) {
    sync = (Synchronization) enumm.nextElement ();
    try {
        sync.beforeCompletion ();
    } catch ( RuntimeException error ) {
        //see case 24246: rollback only
        cause = error;
        setRollbackOnly();
        Configuration.logWarning("Unexpected error in beforeCompletion: ", error);
    }
}

if ( ct_.getState().equals ( TxState.MARKED_ABORT ) ) {
    //happens if synchronization has called setRollbackOnly
    //-> rollback and throw error
    rollback();
    RollbackException re = new RollbackException( "The transaction was set to rollback only" );
    re.initCause(cause);
    throw re;
}

Will this get fixed?

Thanks.

-- Andreas

Hi,

I like the idea, but need to think about the implications. We would need to keep the exception somewhere (in the synchronization that causes it, perhaps?) and then recover it afterwards.

I wonder: what if more than one exception happens, in multiple synchronizations?

Thanks

I see the challenge about multiple synchronizations throwing exceptions but starting with keeping one of them (the first) is a start. I don't really see the point of continuing processing synchronizations if an exception occurs though...

Right now it's impossible to use Atomikos and have decent exception-handling if a DB-constraint-violation occurs in a transaction.