WebSphere Application Server & Liberty

JSR-352 (Java Batch) Post #5: Using StepContext UserData

By David Follis posted Tue July 17, 2018 12:00 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.
StepContext Persistent and Transient User Data

The StepContext we discussed last time also provides access to transient and persistent user data.  As you might expect, these user data fields are there to help the application communicate with itself across batch artifacts within a step.  One, the transient data, is just for use as the step is running.  The other, the persistent data, can be useful across restarts of a failed job.

Setting and getting transient data is easy.  To set the data you use the setTransientUserData method on the StepContext and provide a reference to any Java object you like.  This object instance will be available to any batch artifact that is part of the step.  Therefore, any object you put in there can be accessed across the step.  That could come in very handy for communication between the different bits of Java code that make up your step.

However…remember the caution from last time…for a partitioned step, each partition gets its own StepContext.  Therefore, transient user data set in one partition is not available via the StepContext in another partition.  This might be good.  If an ItemReader sets data to communicate with a chunk listener, it doesn’t want that data confused by an ItemReader processing data in a different partition.  Each partition is working on its own.

Persistent User Data is also pretty cool.  You can’t just set any object in here though.  Because the data will be persisted, it has to be a serializable object so it can be flattened for storage.  For a chunk step the data is persisted at the end of each chunk along with checkpoint data for the chunk.  That’s pretty handy. 

For a batchlet the data is persisted at the end of the step.  Well, what good is that?  Remember that if a failed job is restarted it is possible, depending on what is in the JSL, for a step that completed successfully to be re-executed anyway.  The persistent user data for a batchlet could be used to remember what happened on a previous execution and influence what happens on a restart if you want to re-execute the batchlet rather than just accepting the results of the previous execution. 

If you’re confused by that, don’t worry…restart processing is pretty complicated, and we’ll talk about it here eventually. 

>>Next article in this series
<<Previous article in this series