TransactionAwareBufferedWriter

[jpraet]

The FlatFileItemWriter uses a TransactionAwareBufferedWriter by default. The TransactionAwareBufferedWriter delays writing to the underlying buffer to the point where the transaction is actually committed. To achieve this, it registers a TransactionSynchronization with spring's TransactionSynchronizationManager. When the transaction commits, it is the TransactionSynchronizationUtils that will actually call the synchronization as follows:

public static void invokeAfterCompletion(List<TransactionSynchronization> synchronizations, int completionStatus) {
	if (synchronizations != null) {
		for (TransactionSynchronization synchronization : synchronizations) {
			try {
				synchronization.afterCompletion(completionStatus);
			}
			catch (Throwable tsex) {
				logger.error("TransactionSynchronization.afterCompletion threw exception", tsex);
			}
		}
	}
}

So when there is an IOException when the actual write to the underlying buffer occurs, it is just logged and ignored. The batch job will happily continue with the next chunk. Or am I missing something here?

[arno]

You're right. I guess you can disable this behavior and let the job crash if something goes wrong during the flushing.

[jpraet]

Thanks for the quick response.

When you configure the transactional property with a value of false, a regular BufferedWriter is used. If there is a problem during write/flush, an exception is thrown and the transaction is rolled back. The scenario where the writer has already written on part of the chunk out to the file, and fails afterwards is handled by storing the byte offset position into the step execution context after each commit. So when the job is resumed, the writer will reposition itself, and the non-committed records will be overwritten.

So indeed, transactional=false seems to result in the required behavior, and in my opinion is a more sensible default, because the TransactionAwareBufferedWriter is unreliable.