0
votes

I'm trying to understand what's going on when an exception is thrown inside the writer of a chunk step. I have a JdbcItemReader, a processor and a JPAItemWriter. I used a JdbcItemReader because the processor modifies the value of a field that is also used in the where condition of the reader.

If an exception is thrown inside the JPAItemWriter the transaction is marked as rolled back, the chunk size is set to 1 and Spring Batch sends one item at time to the processor to understand which is throwing the exception.
Is it normal that the item sent to the processor during the retry phase hasn't the original field values? It has the values that were modified during the first run of the processor.
In this way the second run of the processor could be different from the first one.

Anyone can help me to understand what's going on?

1

1 Answers

1
votes

That's normal, because items are cached during the retry. If you want to disable that, you need to set the FaultTolerantStepBuilder#processorNonTransactional() flag.

That said, there are two important details to mention here:

  • You should correctly implement equals and hashcode because those methods are used to identify items in a retry.
  • In a fault-tolerant step, the ItemProcessor implementation should be idempotent, as mentioned in the Fault tolerance section of the reference documentation