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.
In an earlier post we talked about the Job Repository that is used to keep track of the state of jobs currently being run as well as jobs that have finished. The specification doesn’t get into any details about how the repository should be implemented. It just says you have to have something that performs these functions. We’ve also talked about how the Job Repository is implemented in WebSphere Liberty.
One thing the specification doesn’t discuss is how you get rid of things in the Job Repository. Because it doesn’t describe how the repository works, it can’t tell you how to get rid of things. An implementation could choose some automatic archiving system. Or maybe it is just a hole in the implementation that there is no way to get rid of things. This is another one of those questions to ask when looking at an implementation of JSR-352.
The ability to purge jobs is one of the capabilities of the batch REST interface. It has no equivalent in the
JobOperator API because the specification doesn’t discuss job purging.
The DELETE verb is used to purge jobs. The syntax for purge requests is exactly the same as GET requests we talked about last time that let you filter jobs by all sorts of criteria. You can delete all the jobs with a certain application name, with a certain batch status, that were created before a particular time, etc. You can even delete jobs with specific job parameter values.
I’d like to emphasize that the filters you can use to list jobs is the same as the filters you can use to purge jobs. That means that you can use a search to get the list of jobs that match a particular set of filters BEFORE you use that same set of parameters to purge those jobs. It gives you a chance to be sure you got the syntax just right before you accidentally purge all the jobs SINCE last week instead of BEFORE last week.
One other feature is the ability to specify that only the Job Repository entries should be cleaned up. Liberty Batch is also keeping joblogs for each job (that we’ll talk about later on) and purge can clean these up too. But if you have some other mechanism managing those log files, then you can tell purge not to bother hunting them down and just tidy up the repository.