skip and retry for exceptions from chunk listeners

Originally opened as bug 6702 by cf126330

--------------Original Comment History---------------------------- Comment from = cf126330 on 2015-02-03 17:29:10 +0000

Section 8.2.1.4.1 Skipping Exceptions, has the following:

It applies to exceptions thrown from the reader, processor,writer batch artifacts of a chunk type step. It also applies to exceptions thrown during checkpoint commit processing. A failed commit will be treated the same as a failed write.

It doesn't include exceptions from any chunk listeners. For instance, will an exception from ItemReadListener.afterRead() method be eligible for skip or retry? I think they should, as these listeners are extensions of their associated reader, writer, or processor artifact.

Thoughts?

Spec group discussion thread: https://java.net/projects/jbatch/lists/public/archive/2015-02/message/1

Comment from = ScottKurz on 2016-03-24 14:43:25 +0000

Noted that some related issues came up in: https://issues.apache.org/jira/browse/BATCHEE-88

Note that the java.net link above is bad, but we had it archived...pasting it here:

From Scott Kurz on 3 Feb 2015

Cheng,

I agree with your interpretation. The regular before/after (of Read/Process/Write) events should be subject to the same skip/retry logic.

On the other hand subjecting the error listeners to skip/retry gets confusing. I agree the spec should be clarified to state this.

Can you please open a spec bug?

Thanks, Scott Kurz

From Cheng Fang 1 Jan 2015

Section 8.2.1.4.1 Skipping Exceptions, has the following:

  It applies to exceptions thrown from the reader, processor,writer
  batch artifacts of a chunk type step. It also applies to exceptions
  thrown during checkpoint commit processing. A failed commit will be
  treated the same as a failed write.

It doesn't include exceptions from any chunk listeners.Â For instance, will an exception from ItemReadListener.afterRead() method be eligible for skip or retry?Â I think they should, as these listeners are extensions of their associated reader, writer, or processor artifact.

I think this is still a bigger problem for real world projects. Especially when dealing with with container managed transactions. And it's not just for the Listeners, it's also about the final commit during. Note that the spec only says what should happen in case of a error during committing the checkpoint process.

To make this clear again: we have a simple chunk with ItemReader+ItemWriter. The ItemWriter calls some EJB which detects a business error and throws an application exception to signal this. Our chunk has a skippable-exception-classes defined for this exception since we like to at least process all the items we can process.

Right now this does not work, since the application exception marks the whole transaction as rollbackOnly. And the skippable-exception-classes does not yet apply to the chunk commit processing. Or rather it is unspecified and as such not portable.

More specific: we need to define what happens if a chunk part calls Transaction#setRollbackOnly() . Might be easy to do for the writer but is likely a bit more complicated for ItemReader and ItemProcessor.

jakartaee / batch