Bug 6259 - Exception in ChunkStepControllerImpl causes rollback of subsequent step/job status
Exception in ChunkStepControllerImpl causes rollback of subsequent step/job s...
Status: RESOLVED FIXED
Product: jbatch
Classification: Unclassified
Component: RI
1
All All
: P5 major
: ---
Assigned To: ScottKurz
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-07-23 19:15 UTC by m_edgar
Modified: 2014-10-07 14:50 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description m_edgar 2014-07-23 19:15:37 UTC
When an exception occurs in chunk processing (ChunkStepControllerImpl#invokeChunk), additional exceptions that occur during the reader/writer close methods allow for the transaction rollback call to be skipped. Since setRollbackOnly has already been called, subsequent updates to the JBatch database are not committed. The result is that jobs/steps are left in the last state committed to the JBatch database.
Comment 1 ScottKurz 2014-07-23 20:22:44 UTC
Thanks m_edgar for reporting this... sorry but I'm not quite following.

So the scenario starts with an exception coming from the chunk read/process/writer loop... causing a rollback.

What is the next step in the sequence?   

The close() is supposed to happen in a new transaction, so I'm not following what the link is here.

Thanks,
Scott
Comment 2 m_edgar 2014-07-23 20:34:59 UTC
Scott,

The setRollbackOnly is called in the finally block when a throwable occurred. After that, the reader and writer close methods are called. Following those, rollback is called on the transactionManager.

The issue I am seeing is that if an exception is thrown from the reader or writer close methods, rollback is never called on the transactionManager and subsequent updates to the JBatch database tables are made in a transaction that has setRollbackOnly set to true.

Here is the code I am referring to. Notice that the rollback is called after the two close calls, either of which may throw an unchecked BatchContainerRuntimeException.

if (caughtThrowable != null) {
    transactionManager.setRollbackOnly();
    logger.warning("Caught throwable in chunk processing.......
    readerProxy.close();
    writerProxy.close();
    transactionManager.rollback();
    logger.exiting(sourceClass, "invokeChunk");
    throw new BatchContainerRuntimeException ......
} else {
    .....

Just for more context, I am specifically seeing this when an exception is thrown in the reader's open method, which is called prior to the read/process/write loop immediately after the beginning of a transaction.


Thanks,
Michael
Comment 3 ScottKurz 2014-10-07 11:02:49 UTC
Pushed change in 79a64f4ca7b9bcc002ff5e1c4c0e74649e7a3c82.  

Another fix is that while the spec clearly says in "Rollback Procedure" at the end of Sec. 11.9, that the reader and writer are closed before ChunkListener.onError, the RI had been doing it in the reverse order.  Fixed this too.

Noticed a set of problems here which I'm opening up new bugs for.  
Bug 6456 is in the same area of "close" processing, the rest aren't hugely related so I won't mention them here.