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.
We’ve mentioned the Job Operator interface before. This is the API that allows an application to start, restart, and stop jobs. Coming from a mainframe background, it always seemed odd to me that you would want to have a running application program call an API to start a batch job. Batch jobs are something run on a schedule with some sort of enterprise scheduler calling the shots. And some of the implementations of JSR-352 have provided extensions to the specification that allow you to do just that.
But your enterprise scheduler could easily start a JVM to run an application that, in turn, runs a batch job inside that JVM. It looks a little different to operations than their “normal” batch job, but it is a batch job all the same.
The best use of the Job Operator API, I think, is to spin off batch processing from OLTP applications. Suppose your banking application is processing an ATM cash withdraw and it needs to launch some fraud detection processing. That processing needs to happen asynchronously to the transaction and is, perhaps, complicated. The transaction could use the Job Operator API to launch a batch job within the same server that is processing the ATM transaction to run through the fraud detection process. Or something like that.
Job Operator also provides a whole set of APIs to allow you to poke around in the current batch environment. You can get lists of running jobs or lists of jobs that have already run with a particular job name. You can find all the executions of a particular job instance (attempts to restart a particular job). You can even access to the
StepExecution objects for the steps within a job.
Another method allows you to access the job parameters used to submit a job execution. That’s actually pretty important. If you are writing code to restart a failed job, remember that the spec requires you to provide job parameters for the restart. You can use the
getParameters method to fetch the parameters used for a prior execution of a job you are about to restart, giving you a chance to adjust them, if necessary.
Remember also that having access to the
StepExecution object allows you access to the Persistent User Data for the step. For a running job, this is the last persisted user data (at the last checkpoint if it is a chunk step). If your application is leaving “notes” about its progress in the user data, this is a way to get a peek at it from outside the job.
There are probably other choices for a song, but I’ll go with “Smooth Operator” by Sade.