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.
-----
This is an interesting one. I’m not entirely sure how useful it actually is in the real world, but structurally it lays some groundwork we’ll see used in other BatchEE things. Essentially this batchlet allows you to issue a single SQL statement without having to write any code.
Let’s start with the connection to the database because we’ll use that for other JDBC related things. The batchlet extends another BatchEE class called JdbcConnectionConfiguration. That takes an injected value of the JNDI name for the datasource you want to use. This is the easiest thing to do. If you don’t have a JNDI name you can also directly provide a driver class name, a URL, and a userid/password and the connection configuration class will try to use those to get a connection to your datasource. This class doesn’t really do very much…just gets a connection to the specified datasource, but it factors out that so it doesn’t clutter up the batchlet or, as we’ll see later, the reader etc.
Which brings us to the batchlet itself. This too is pretty easy. It uses the connection configuration to get a connection to your datasource, then prepares and executes the SQL statement you injected as a batchlet property. There’s nothing clever being done here…it just executes the statement you gave it. Then it closes and commits to tidy up and we’re all done. The batchlet’s stop method does nothing.
Whatever is returned by the execution of the SQL is returned from the batchlet. This becomes the exit status value for the step. You can use this in the JSL in conditional routing. You might be able to try to insert a row and conditionally go to one step or another depending on whether the insert works or not (maybe a row with that key already exists). Or delete a row and make a decision about what to do next depending on whether it existed or not.
You could probably do some other things like a SELECT COUNT( ) and make a decision based on the number of things found (less than 100, we’re pretty caught up so move on, more than 100 and we need to do some processing…or something like that).
When I started writing this I thought it was rather odd that you’d have to basically hard-code the SQL statement which seemed rather limiting to me, but now that I’ve thought about it some I can see that you could actually do some pretty clever decision making with it…all without actually having to write any code.