My question relates to Spring batch and transactions.
Say I've chosen a commit-interval of 50 for one of my steps.
Also suppose I have 1000 records in all and amongst those records one will cause the itemWriter to fail thereby causing a rollback of the entire chunk (50 records in my example).
What are the stategies to make sure that the 49 valid records are written to database after the job has completed (and ignored the problematic chunk)?
After some researching, I came up with the following:
If an item writer fails to commit a chunk (here 50 items) thereby causing a rollback, Spring Batch will rerun each item of the problematic chunk individually with one commit/transaction for each item.
Therefore, all 49 items will be present in database except the one item that caused Spring Batch to roll back the chunk.
We focused on skipping items during the reading phase, but the skip configuration also applies to the processing and writing phases of a chunk-oriented step. Spring Batch doesn’t drive a chunk-oriented step the same way when a skippable exception is thrown in the reading, processing, or writing phase.
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 quote the paragraph from book Spring Batch in Action, Manning.
It is quite tricky, the rollback behavior is different depend on whether the exception is thrown in reading, processing or writing.
Hope this help others.
