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 can be found
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.
As usual, let’s review. The Step Context has methods on it that allow an application to set and get what is called Persistent User Data. The data itself is just a serializable object. The spec says that the data is persisted at checkpoints. For a step that doesn’t do checkpoints (a batchlet) it is persisted at the end of the step. The data is available on a restart.
What does that mean? Well, basically it provides a notepad where the application can put things that it might want to remember (besides the reader and writer checkpoint data) for a restart. This could be something from the processor or maybe something from one of the listeners that needs to be available for a restart.
Well, if the data is persisted at checkpoints along with checkpoint data, why would you want a flush method to force it to persist outside that scope? I suppose it is possible you might have data you need to remember that isn’t tied to the chunk processing. That seems rather specialized.
The real use case is for a batchlet. We normally think of a batchlet just doing some piece of processing that isn’t in a loop. If you need to do it in a loop, you’d do it with a chunk, right? Well, not always. There might be reasons you want to manage the loop yourself. Or perhaps this is code that used to be run as a stand alone Java program (just driven from a main()) and it was easier to convert to a batchlet than rewrite into a chunk.
Regardless of how you got there, you might find yourself mid-batchlet and need to persist something in case the job fails. That way when the job gets restarted your batchlet can get the persistent user data from last time and pick up where it left off or do whatever it needs to do with the data it remembered.
Presumably this would just be another method on the Step Context.
It does feel like there might be some complexities about this as it interacts with the automatic persistence occurring in a chunk, but I can’t see what it would be. If you can think of something feel free to comment in the issue linked above.