WebSphere Application Server & Liberty

Jakarta Batch Post 134: Apache BatchEE – FlatFileItemWriter

By David Follis posted Thu April 22, 2021 09:53 AM

This post is part of a series delving into the details of the JSR-352 (Java Batch) specification. Each post examines a very specific part of the specification and looks at how it works and how you might use it in a real batch application.

To start at the beginning, follow the link to the first post.

The next post in the series is here.

This series is also available as a podcast on iTunesGoogle PlayStitcher, or use the link to the RSS feed

This seems pretty easy given the FlatFileItemReader.  This is just an ItemWriter that allows you to inject properties for the file path/name, a line separator, and an encoding to use.  It handles the basic file stuff as you’d expect, incorporating the separator and encoding along the way. 

How does it convert the Objects provided from the reader/processor into something it can write into a flat file?  The assumption is that toString( ) will probably get what you want.  The Object is coming from your application code (probably the ItemProcessor) and so you could implement your own toString( ) that returned whatever you wanted the writer to put in the file. 

If somehow that doesn’t work for you, you could always just extend the FlatFileItemWriter with your own implementation because the toString is done in a method called preWrite that you could override to do something more complex that toString if you have to.

Well what about restart?  The FlatFileItemReader handled checkpoint data and repositioning itself within the file at the record it was at when the last checkpoint committed.  What does the writer do?  Well, it will position itself at the location of the last checkpointed write, but it isn’t really clear to me that doing that will just overwrite anything written to the file after the last checkpoint.

The implementation pulls in another BatchEE extension called a TransactionalWriter.  I spent a little time poking around in this and frankly I’m skeptical.  Maybe it works.  I didn’t spend that much time on it.  But I’m highly suspicious of anything that tries to make a plain file transactional.  There’s some stuff in there with JTA User Transactions and maybe that somehow takes care of it. 

Generally any Java Batch job that is writing output to a basic file is going to have to do some work to sort things out when there are failures and restarts because normal file I/O just doesn’t roll back. 

To be clear, I’m not saying I know this doesn’t handle rollbacks properly…I’m just skeptical.  I would be delighted to be convinced it handles restart/rollback situations correctly.