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.
-----
The issue can be found here.
If you want to run a partitioned step (running multiple copies of the step at the same time) then you have to create a partition plan. You can do that either statically in the JSL itself or use a Partition Mapper to create one dynamically. The plan consists of properties that will be provided to each partition. Typically, these properties help each copy (partition) know what range of data it is supposed to operate on.
When you define the plan you specify partition numbers (starting with zero) for each partition and assign (probably) different property values based on the partition number. Thus, the partition number is a known thing to the batch container based on information you provided in the partition plan.
And so you might reasonably expect that there would be some way to determine from inside the running partition which partition number you are. You might want to create some sort of output file from within the partition and you want to make sure each partition uses a unique file name. An obvious place to get a unique value would be to use the partition number. If only you knew what it was.
Turns out there is no way to get the partition number. The batch container knows and could certainly provide it, probably as a method on the Step Context. Would it throw an exception if you called it from a non-partition thread?
In the meantime you can get around this by simply adding a property to the partition plan that is set for each partition to the partition number. You’ll feel a little clunky doing it because it seems (at least in retrospect now) that this was sort of an obvious thing to need.
This strikes me as one of those reasonably valuable and yet pretty easy to implement enhancements that should really be added to the specification.
Join in and let us know how you feel about this issue or any of the other ones starting from the link above. We’re always looking for help in defining and implementing enhancements to the batch specification.
#JSR#WAS#websphere#WebSphereApplicationServer(WAS)