WebSphere Application Server & Liberty

JSR-352 (Java Batch) Post #70: Job Execution Events

By David Follis posted Wed December 04, 2019 07:40 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.

This series is also available as a podcast on iTunesGoogle PlayStitcher, or use the link to the RSS feed

Last time we talked about the nodes in the batch topic tree where messages (events) get published at significant points in the lifecycle of a job instance.  This time we want to take a different branch and look at job execution events.  Those are under batch/jobs/execution instead of batch/jobs/instance

Just quickly, a job instance is created when a job is submitted.  A job execution is created when the job is run or restarted.  One instance can have one or more executions. 

Which means that a job execution has some of the same events (topics) as an instance.   Those are the ones that cover when the job ends.  There are events for the execution being completed, stopped, and failed.  These will happen in addition to the similar events for the job instance. 

A job execution does not have stopping or purged events because those operations occur at the job instance level.

A job execution doesn’t have the submitted or dispatched events (or the JMS-related events either).  Instead we have execution/starting and execution/restarting events that tell you WHY this execution is here.  You only get an instance/submitted event for the original creation of the job.  And the instance/dispatched event doesn’t tell you why, you need the execution/starting or execution/restarting events to tell you that.

So what?  Well, again consider that you might be building some sort of monitoring that would subscribe to these various events and try to show what is going on.  You would need this information in order to show (in some fashion) a job that was restarted and running vs. a job that was on its first try vs. a job that had failed and hadn’t been restarted yet.  The distinction might make a lot of difference. 

If you look closely at the topic tree, you’ll notice there is one more node directly under batch/jobs/execution that I skipped.  I’m saving that for next time..