This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
To start at the beginning, follow this link to the first post.
---------------
If anybody is paying close attention, you might wonder what happened to post #88. Well, if you look back a few posts you'll notice that there are two post #86's. The second of those should have been '87' and the post before this one would have been '88'. So I skipped to '89' this week to get back on track. Not that it really matters.
This week we’re back to talking about Java Batch. In particular, servers which use the Jakarta Batch (formerly JSR-352) features in Liberty. If you’re using this capability to run batch jobs inside Liberty you’ll need a Job Repository.
Conceptually the Job Repository is basically the JES Spool (if that helps). It is a place where the batch runtime can keep track of what is going on. It knows which jobs are running, which step it is on, might have checkpoint information about a step and, for jobs that have finished, it knows how they turned out (exit or completion code for example). The batch specification just says you have to have one of these in your implementation but doesn’t talk about how it actually is implemented.
In Liberty there are two Job Repository implementations. The first and easiest one is the in-memory repository. In this case all that information is just kept in structures in the Java heap. All the operations to ask about job status and everything else work just as the spec requires. The catch, of course, is that if the server goes down all that knowledge goes with it. It also means that if you’re not purging old job information it is just building up in memory which could eventually be a problem. The in-memory repository implementation is really just meant for development where you don’t really have information about production jobs that you care about. And, in fact, it might be better if you can just forget about everything you’ve done and the mistakes you’ve made by restarting the server (well, the server will forget, you might not).
For jobs you care about, there’s the database implementation of the repository. That’s done in Liberty using Java Persistence Architecture (JPA) which is a layer that handles the differences between different databases without the batch code having to have separate code for subtle SQL differences. Configured this way, all that job information is hardened in whatever database you’re using.
So what about messages? Well, you’re looking for CWWKY0005I which will tell you about the persistence service being used by the batch container. It will indicate that either the in-memory or JPA persistence service is being activated or deactivated. This can come and go as the server starts up and different things get initialized. So it isn’t uncommon to see the in-memory service get activated and then get deactivated when the JPA service is activated.
To make it easier to figure out what you ended up with, we also issue CWWKY0008I which tells you which persistence service the batch feature wound up using.
If you’re running production batch jobs where you care about what happened to the jobs you’ll want to be sure the JPA service is being activated and used.