How to control transaction boundaries

[ryanc]

I have a batch job that reads a single row from the database (ItemReader), performs some time intensive calculations (ItemProcessor) and then inserts a handful of rows into another table (ItemWriter). I am having trouble with deadlocks and added retry support thinking restarting the transaction would resolve the problem.

Deadlocks are happening so often (the transaction is kept open for at least 10-20 seconds and the task executor is usually executing 8 at once) that performance goes out the window when the entire 10-20 second operation has to be redone before the ItemWriter gets to try again.

Ideally I would like the read and process step to happen in a separate transaction so if the write fails only the write is retried (reduce the amount of time the write transaction is held open). What is the best way to model something like this in spring batch?

The only way I can think of is to split the read and write portions into separate read/write steps and during the calculate step store all the calculated data into a csv file and the persist step can read for the csv generated by the previous step and write to the db.

What have others done?

[ryanc]

I haven't made any progress on this (been working on other issues).

It seems like the best case would be if when a write fails the retry only retries the write (in a new transaction). I briefly looked at the code and didn't find an obvious answer if that was already the case.

[Dave Syer]

One possible workaround with no changes to framework code is to move the processing logic into the reader.

There is a JIRA issue (http://jira.springframework.org/browse/BATCH-1281) calling for the framework to allow processor results to be cached.