WebSphere Application Server & Liberty

JSR-352 (Java Batch) Post #31: Listen to the Rhythm of the Falling Rain (or the Chunk Processing…)

By David Follis posted Wed February 27, 2019 08:14 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.

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

The next post in the series is here.

Apologies to The Cascades this time (had to look that one up..). 

This time we’re going to consider three Listeners you can implement around Chunk processing.  We already talked about the Chunk Listener that gets control around the entire Chunk, but there are also listeners around the individual read, process, and write operations. 

The Read Listener gets control before and after the ItemReader reads an item to process.  The after method gets passed the object that was returned by the reader which gives you an opportunity to look it over and do any post-reader processing you might need to do.

The Processor Listener gets control before and after the ItemProcessor processes the item that was read.  The before method gets the object returned by the reader, giving you a chance to do any pre-processing work.  The after method gets both the object that was read and whatever object was returned by the processor.  This gives you a chance to look at both the input and output from the processor.

Finally, the Writer Listener gets control before and after the ItemWriter writes the list of items returned by the processor in this chunk.  The before and after methods both get the list of items to write.  This gives you a chance to do something with the list both before it gets written and afterwards. 

But that’s not all!  All three of these listeners also have a method that gets control if an exception is thrown from their respective artifact (so the ItemReadListener has an onReadError method that gets control for an exception from the ItemReader, etc.).  All the methods get passed the exception thrown.  This means you can create an exception object and use it to communicate between the reader/processor/writer and the listener.  The processor and writer listeners also get the item (or items) being processed/written. 

Be careful though…the onError methods are not catching the exception.  They just get informed that it happened.  Handling the exception is something we’ll get into in future posts. 

So, what good is all this?  Probably you’ve tried to create somewhat generic readers, processors, and writers that do specific tasks (read from this data source, do this processing, etc).  The listeners around them give you a chance to smooth out the edges between them or do some specific processing for this job that you don’t want in the general use reader etc.  As with most listeners, it is just a chance for you to get control around the mainline processing and do some extra stuff.