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.
-----
When we talked about the Java Batch specification, one thing we discussed was that the spec doesn’t say exactly how an implementation keeps track of information about jobs it is running (or jobs that have run in the past). It isn’t just information about whether the job was successful or not. An implementation has to remember checkpoint information for any chunk steps as well as the completion status of any steps that were run so it can do proper restart process if the job fails.
Since this is the first post in a series discussing the implementation of Java Batch in WebSphere Liberty, I thought I’d start off by talking about how the Job Repository is implemented by Liberty.
Actually, we offer some options about implementation. If you do nothing at all in the server configuration (except configure the batch feature, of course) then, by default, the Job Repository will be implemented using in-memory structures.
On one hand, this is really cool. You don’t have to set up a database. You don’t have to do any configuration. It just works. And if you make a mistake or do some things you’d rather just forget happened (and we’ve all done that…) you can just restart the server and the whole repository contents will be thrown away. This is just awesome if you are doing development or just playing around with batch.
Do remember that all the information, including serialized checkpoint objects, is being kept in memory. That takes up room in the heap. If you leave the server up for a long time and run a lot of jobs, information about old jobs could be essentially a memory leak. Purge some jobs or restart the server to tidy up.
Of course, if you actually care about the jobs you are running and want to be able to reliably restart jobs when bad things happen, you want a more persistent repository. Fortunately, Liberty provides a real persistent option that we’ll talk about next time.
Since this week was mostly about the in-memory Job Repository, our song is going to be “The Way We Were” (Barbra Streisand). Jobs that are too painful to remember, you simply choose to forget – by restarting the server.