Issue Details (XML | Word | Printable)

Key: BATCH-786
Type: Sub-task Sub-task
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dave Syer
Reporter: Dave Syer
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Spring Batch
BATCH-220

Transactional flushing for file writers

Created: 18/Aug/08 09:56 AM   Updated: 29/Sep/08 09:09 AM
Component/s: Infrastructure
Affects Version/s: 1.0-m3
Fix Version/s: 2.0.0.M2
Security Level: Public (Public Issues)

Time Tracking:
Original Estimate: 0.5d
Original Estimate - 0.5d
Remaining Estimate: 0d
Time Spent - 0.25d
Time Spent: 0.25d
Time Spent - 0.25d Time Not Required


 All   Comments   Work Log   Change History   FishEye   Builds      Sort Order: Ascending order - Click to sort in descending order
Dave Syer added a comment - 18/Aug/08 11:52 AM
Added TransactionAwareBufferedWriter and used it in file writers.

Flush and commit. Sunny day is always fine, but failure and rollback are less obvious. When is file pointer and other state updated?

  1) Flush fails in TX synch. TX will roll back but state is already updated unless it is also managed in a TX synch.

  2) Flush in TX synch and commit fails. TX may roll back depending on TX manager. State is already updated.

2) is more of a corner case, but without an XA file resource we are not going to make any progress. 1) is relatively mainstream.

1) only applies to flat file and xml writer cases (there is no persistent state in other writers). If the flush fails then the persistent state will be fine after the rollback, but the local volatile state will be inconsistent, so processing cannot continue (retry or skip). To fix that we would have to read the volatile state back from the database at the start of every chunk.

On the other hand... if a flush has failed, the process in trouble for loads of other reasons. E.g. there is no way to know the contents of a file after such a failure. We typically deal with such pathologies by truncating on restart - means that the failure has to be fatal (e.g. use FlushFailedException). In which case there is no need to worry about the volatile state either - it won't be used if the exception is always treated as fatal.