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 iTunes, Google Play, Stitcher, or use the link to the RSS feed.
The issue can be found here.
This time we’ll take a look at a requirement for another listener. This one would have been helpful a few weeks back when we were talking about initialization and cleanup for application artifacts used by a step. Before we get into it, let’s have a quick review of listeners.
The batch specification defines quite a few different listeners that can be implemented to get control at different points in the execution of a job or (mostly) a step. There’s a job listener that gets control at the beginning and end of the job. But for each step you can also define a listener to get control too. A chunk step has a bunch more listeners around the reader, writer, and processor, plus other listeners to handle error conditions for skip and retry processing.
Interestingly, for a step you just specify the class that implements a listener as part of the step and the batch container will determine which listener interface it implements and make sure it gets control at the right times. You don’t have to specify in the JSL that this listener class is a Read Listener. It implements that class, so that’s what it is.
You can, of course, have a single class implement multiple interfaces and the listener method names are all carefully chosen so they don’t interfere. You can have one class that implements all of the listener interfaces if you want to and the batch container will make sure the right methods given driven appropriately.
The specification is also very clear that there is no particular order to drive when you have multiple classes that implement the same listener interface for the same step (or for the job).
So what about the partition listener? Well, as it stands right now in the specification there is nothing that gets control around each partition like a step listener does for the whole step. There’s a chunk listener that gets control for each chunk (if the partitioned step is a chunk step). It would be nice to have something that got control on each partition thread before and after each entire partition.
The only way to emulate that behavior now is with a chunk listener with special logic to help it figure out if this is the start of the first chunk or the end of the last one and emulate before/after partition behavior. Just having that as part of the specification would avoid having that logic in the application.
This one should be easy enough to implement by adding another interface and putting the appropriate processing around execution of the partition. At least it sounds easy to me…I could be wrong…