WebSphere Application Server & Liberty

Jakarta Batch Post 128: Optional Writer

By David Follis posted Wed March 10, 2021 07:55 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.

When we talk about a chunk step we always talk about the reader and processor running in a loop and when we reach a checkpoint the writer gets control.  But technically you don’t have to have a processor.  The JSL element doesn’t have to be there.  Well what happens?

If there is no processor defined then whatever result comes from the reader is accumulated as it were the output from the processor.  When a checkpoint is reached, the list of those objects is passed to the writer. 

This scenario basically covers the case where the reader itself is doing the “processing”.  Suppose the step is scanning some database table producing a report of all the clients who match some criteria.  You could have the reader read the entire table and the processor filter out the results to be given to the writer.  But you might be able to use a simple WHERE clause in the SQL used by the reader to restrict the results to just the ones you want.  There’s no processing to do.  So the processor is an optional part of the chunk.

Which brings us to the issue at hand.  The spec requires you to have a writer.  But do you really need one?  The only thing you really HAVE to have is the reader because it controls when the chunk loop ends (by returning a null).  The writer could just do nothing at all but return.  So technically it would seem that we could allow a chunk step to be defined without one.

But would you ever want to?  Allowing this would permit the creation of a chunk step with just a reader and a processor, or even with just the reader and nothing else.  Is there a use case for either of these?

Certainly the reader/processor combination makes sense.  Suppose you’re just hunting through a table looking for rows that match some elaborate criteria (beyond just a WHERE, maybe some other analysis is required).  You don’t actually need the specific rows, you just want to know if any exist.  Perhaps there’s some flow control in the job based on the results of this search.  Then you could have a reader reading rows and a processor doing the analysis and setting the step exit status based on what it finds.  There’s nothing at all to write. 

Would you ever have a chunk step with just a reader?  I suppose you could.  I start to wonder if maybe you would be just as well off with a batchlet, but perhaps there are cases where you’d want the transactional help when the step fails and you need to restart.  Or perhaps there’s something you could do with a reader, skippable exceptions and the skip listener.

Seems a worthwhile change to me.  What do you think?  The link’s right up top…
0 comments
63 views

Permalink