rollback mechanism for chunk oriented processing strategy of Spring Batch

Question

As we all know, spring batch uses chunk oriented processing since the version 2.0.

Does it mean that, if an exception occurs in the item writer, the Data Source Transaction manager will roll back the whole chunk or only the related item?

Actually, I gave it a try and saw that the framework rolls back the whole chunk. That's not what I need because I do not want, let's say, 499 items which have been processed successfully to be rolled back in a chunk consisting of 500 items when the last item causes an exception to be thrown.

The only solution I was able to find is to add the attribute below to my tasklet. However, I am not sure if this is the right thing to do.

<batch:transaction-attributes propagation="NOT_SUPPORTED"/> 

Another opinion was to simply reduce the chunk size to 1 (one) but that one also doesn't make much sense.

Maybe Spring Batch is not suitable for my problem domain. If so, please tell me so I won't be struggling with those kind of framework specific behaviour anymore.

Any suggestions would be greatly appreciated.

Answer 1

Your right : the whole chunk lot is rollbacked.

I faced the same problem and did the following :

• adapt the batch size according to the database (I was using batch statement to save my updates). 25 was a good value for us: better than 1 (batch benefits), not too much (huge transactions).
• relaunch this step a limited times : we enabled re-executing this task 3 times maximum.

This was well working because corrections could happen during the batch processing (corrections done by GUI).

At the end of our process, all datas marked as failed and retried 3 times were definitively marked as failures in our batch report : then need a human correction or a special process.

Answer 2

The solution might be to stop propagating the exception in writer and catch it. This will prevent batch from rolling back as you catch the exception and do your custom handling.

Answer 3

You can open an different transaction inside the writer method with Propagation.REQUIRES_NEW to handle this use case.