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.
Yup…it is time to talk about the
ChunkListener (I know, I know, but it is hard to come up with interesting titles to these).
In earlier posts we’ve talked about the Job and Step listeners. Lately we’ve been talking about a chunk step and so it is time to talk about the Chunk Listener. The Step Listener still gets control around the whole step, but the Chunk Listener is a chance to get control around each checkpoint. We still need to talk about how checkpointing works. Maybe next time, if I can think of a clever title (don’t hold your breath).
Like the Job and Step Listeners the Chunk Listener has methods that get control at the beginning and end of each chunk. These are called, not surprisingly,
Understanding the timing of these is important. Both before and after methods are driven inside the chunk. That is, the transaction that wraps the processing for each chunk begins before the
beforeChunk method is driven and the transaction is committed after the
afterChunk method. That means anything you do inside these methods that is transactional in nature will get committed along with the chunk transaction (or rolled back if that’s what happens).
There’s also an
onError method. If there is an exception in processing the chunk that isn’t handled in some other way, the
onError method will get control instead of the
afterChunk method. The
onError method gets passed the exception that is causing the chunk to roll back and
onError gets control before the rollback occurs.
That means you can tell whether a given chunk will commit or rollback based on whether
onError in the
ChunkListener gets control.
How is that useful? What might you want to do in a Chunk Listener? Honestly, I haven’t really run across any common use cases, but I’m sure there are some. You could use the
onError distinction to provide some sort of status update to someone monitoring the job. Maybe update something about how many chunks were committed or rolled back in this step. Although that information is also available through the
JobOperator interface as part of the Step Execution object. Maybe you want to push the data somewhere instead of having to ask for it.
Other ideas? Let me know….