How to prevent Spring Batch from resubmitting chunk items in the event of a skippable exception thrown by an item writer?

0
votes

I am in reference to a Spring Batch book by Manning publisher. To quote a paragraph from the book:

When an item reader throws a skippable exception, Spring Batch just calls the read method again on the item reader to get the next item. There’s no rollback on the transaction. When an item processor throws a skippable exception, Spring Batch rolls back the transaction of the current chunk and resubmits the read items to the item processor, except for the one that triggered the skippable exception in the previous run. Figure 8.3 shows what Spring Batch does when the item writer throws a skippable exception. Because the framework doesn’t know which item threw the exception, it reprocesses each item in the chunk one by one, in its own transaction.

I would like to know what is the official Spring Batch terminology for the process described above whereby an item writer throws a skippable exception and the chunk is resubmitted one by one?

My item writer sends emails and I want to ensure this process of resubmitting and reprocessing the chunk items one by one does not occur in any circumstance for any exception (this would resend already sent emails in the chunk which would be an issue). How can I ensure that resubmission of the items (or whatever it is called) does not occur?

1
spring-batch

1 Answers

0
votes

The best way is to NOT throw a skippable exception in the first place. If it's an exception you are explicitly creating due to expected business/validation rules, I would advise instead leveraging the "filter" pattern of just returning null from the processor. Alternatively, you could use a Classifier processor/writer to handle invalid records differently from valid ones.

If throwing the exception is unavoidable, I would suggest you use try/catch and handle it within the ItemProcessor and handle it there.

As for an overview of what the framework does when a skippable exception is encountered, check out this older answer.