1
votes

I am using Spring batch JDBCCursorItemReader to read set of data from a table. Once data is read spring batch will process each row in a chunk(reader, processor, writer). Now I want to update/delete those records which my reader fetched to avoid reprocessing by another instance of same job. Can someone please tell me how can I do this in reader?

Thanks

1
You don't do that in the reader, that is only for reading... You want to do that in your writer of maybe a custom chunk listener. - M. Deinum
But I want to update/delete as soon as my reader fetch those records, not after processing, as writer will get executed only after processing can I use writer for this? - springenthusiast
And what are you going to do when the operation fails? Your record is already marked as processed while it isn't... Then what? Also it will only be visible after the transaction committed and you don't want a transaction per record as that would kill your performance. Wouldn't it be easier solved by not allowing multiple instances of the job? - M. Deinum
Thanks for reply.As per my requirement I need to run multiple instance of same job, so I want to update the input rows to intermediate state, which will not be processed by other instance. If step/job fails I will update back to initial state so it will be reprocessed by other instance. If I use chunk listener can I get all record read by itemreader at once to update to intermediate state? - springenthusiast
Why are you running multiple instances of the same job to process the same data at the same time? There are better ways to orchestrate the parallel processing of data within a single job instance that prevent this type of issue (partitioning, etc). - Michael Minella

1 Answers

0
votes

Like it has been pointed out this might be a bad design idea. However if your sure this is what you want to do,

create a two step job,
step a, with commit interval as 1
Read the record
Write the updated record with the current job execution id
step b
Read the record where job execution id is current job execution id
process and update as needed

Notes

  1. I do not recommend this approach for reasons stated in the comments
  2. A commit interval of 1 would kill you performance wise so this approach if ever used should be for a low volume job only.