WebSphere Application Server & Liberty

Jakarta Batch Post 127: Transactions Around Open and Close

By David Follis posted Wed March 03, 2021 08:03 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

The issue can be found here.

There is also issue 125 which is similar/related. 

In the current specification for a chunk step a transaction is started and then the open methods for the reader and writer are called and the transaction commits.  Similarly, a transaction exists around the close processing for the reader and writer together.

These items propose that these two transactions should be optional, or perhaps that there should be separate transactions for the reader and writer.

As we discussed last time, having transactions at all around open and close processing presumes some activity is going on in there that is transactional in nature and needs the commit to harden it.  There is no activity by the batch container that needs to be coordinated with open or close processing that would need to be part of the same transaction.  Which means the overhead of the transaction may be unnecessary and just clutter things up. 

On the other hand, it could well be that there are transactional updates being made in open (or especially in close) processing.  This seems most likely for the writer which may hold off making some final update until the close happens.  Perhaps it needs to write a total count somewhere into a transactional resource. 

For these situations a transaction makes sense, but why just one?  Is it always the case that whatever the reader and writer are doing needs to commit together?  Would some error in closing the reader preclude the writer from performing its close processing?  An exception thrown from the reader’s close processing shouldn’t prevent the writer’s close processing from happening and certainly shouldn’t (necessarily) prevent whatever updates it might make from committing. 

In this case we might like to have independent processing and transactions for the reader and writer open and close processing.  But how would you indicate your preference?  Presumably some syntax in the chunk element would do it.  There are a lot of combinations that are possible:  one transaction for reader and writer, separate transactions, a transaction for just the reader, or a transaction for just the writer.  You might want to have all of those possibilities for both the open and close processing to allow for different behavior.  Perhaps separate attributes for open and close with four values for each attribute.  The default, of course, would be the original behavior.

Have some thoughts or ideas around this issue?  Comment at the link(s) above!