WebSphere Application Server

JSR-352 (Java Batch) Post #56: REST Interface page and pagesize Parameters

By David Follis posted Wed August 21, 2019 07:34 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
-----

All of the GET services that can return more than one result, as well as the DELETE service to purge jobs, support the page and pagesize parameters.  What do those do? 

The idea is that some services, such as GET a list of all jobs, might return a really really large result set.  There could be tens of thousands of jobs in the Job Repository and you might not really want all of the information about all of those jobs coming back in response to your request.

The pagesize parameter is used to limit the number of records returned.  The default is fifty.  Well, if we have a page size, that means the results are broken up into pages of that size.  And so you can use the page parameter to indicate what page you want. 

Suppose you GET a list of jobs matching some criteria and there are two hundred such jobs.  By default the GET request will return the first fifty of those (pagesize=50 and page=0 being the defaults).  To get the next fifty, you need to specify page=1 and so forth to get the remaining three pages of data. 

Of course, you can also change the page size (to 200 in this case) and get all the results in one response.  If you don’t know how big the result set is and you are sure you want it all no matter how big it is, just set the page size to something really big. 

There is, of course, a small problem with this approach.  The state of the Job Repository may be changing between requests.  The result of a request isn’t actually kept around between calls since we have no way of knowing if you’ll be back for the rest of it.  If you ask for the first 50 of a result that contains 200 records, then come back and ask for the next 50, there is no guarantee that nothing has changed in between.  A result in the first set could now be part of the second 50 records (possibly if somebody purged some jobs that were in the first 50).

Which brings us to the really weird case.  Suppose you are using DELETE to purge jobs.  Suppose you are trying to purge those 200 jobs we found earlier.  If you purge with pagesize=50 and page=0 (defaults remember) then the first 50 jobs matching the purge criteria will be deleted.  But that leaves only 150 jobs remaining, and if you treat it like you did search and move on to page=1 you will purge the second 50 results, but those are really the third 50 results from the original query as the new result set is only 150 jobs.  Once that completes there are only 100 jobs left and a matching purge with page=3 will delete nothing as there aren’t any jobs on that ‘page’ of the results anymore.  But there are still 100 jobs left.  The trick here is to just keep deleting page=0 until there is nothing left.  Or do a GET and page through the results (which hopefully aren’t changing too much underneath you) to get a count and then set the DELETE pagesize to that amount. 

Hopefully that was clear…. Our song this week is obviously “Turn the Page” by Bob Seger.

0 comments
6 views

Permalink