How can I rollback a step?

[savvas]

Hello,

We currently have the following step defined:

<step id="readWriteWorks">
			<tasklet>
				<chunk reader="reader" processor="processor" writer="writer" commit-interval="500">					
			</tasklet>
			<end on="COMPLETED"/>
</step>

Under this configuration whenever an Exception occurs, while processing a chunk, that chunk(of 500) import will be rollbacked. But what if one wants to rollback the whole step instead of just the chunk.
What if one million rows have already been imported prior to the failed chunk and we want those rows to be part of the transaction?

Is there a configuration option for that?

Thank you,
Savvas

[arno]

you can't rollback a whole step (that's the point of chunk-processing). The only think you can is using a compensating transaction in the next step ("rolling back" the items yourself, because you marked them in the previous step).

[savvas]

Hi Arno,

Isn't that a big limitation though? Having to "manually" rollback?
I'm pretty sure there are many use cases where the requirement is "all or nothing"..

I am wondering what happens if I don't define a chunk and just implement a step. Would that step be executed in one transaction?

Thanks,
Savvas

[arno]

Isn't that a big limitation though? Having to "manually" rollback?
I'm pretty sure there are many use cases where the requirement is "all or nothing"..

some scenarios are exactly the contrary: a bad item shouldn't compromise all the other items (items in a batch job are supposed to be independent).

You can set up a very large chunk-size or even set your own completion strategy (chunk-completion-policy attribute) to decide when the commit should happen, but the rollback can take a long time, depending on the number of items (long time can mean hours or even days).

I am wondering what happens if I don't define a chunk and just implement a step. Would that step be executed in one transaction?

you can implement a Tasklet for that.

[savvas]

thanks very much for all the input. The Tasklet approach seems more appropriate for our use case.

Regards,
Savvas