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 handy little class combines several things we’ve talked about already. Essentially it is a standard ItemReader that you can use to pull records out of a database table. If you think about how you’d write something like that, you’ll have some obvious questions. How does it know where the database is? How does it know what table? How does it know what rows to select and what columns I need? Once it has a row, how does it produce the Object that gets passed to my ItemProcessor?
If you think back over the past weeks, you’ll see we’ve already got answers to all of that. Just like the JdbcBatchlet, the JdbcReader extends JdbcConnectionConfiguration which handles all the issues with getting a connection to the database using injected values from the JSL.
And just like JdbcBatchlet, the JdbcReader allows you to specify an SQL statement to be executed. This time it will get a result set back that it has to iterate through instead of just returning the result as the exit status. That’s all good too.
But how does it know how to convert the results into an Object? Well, it does it almost the same way that the FlatFileItemReader does it. For the flat file the reader would, by default, just return a String that was the contents of the file record. However you had the option of implementing a LineMapper class that would convert that String into an Object.
In the JdbcReader you have to provide a RecordMapper. The mapper will get the result and can map it into any Object it likes, however it likes. The results are added into a linked list maintained by the JdbcReader and that will be returned as ‘read’ results until it runs out.
This Object would naturally be the actual class expected by your ItemProcessor.
All in all a pretty handy little class that allows you to read records from any JDBC accessible datasource, handling all the gorp while you just worry about mapping the results into your object.
That said, it looks to me as if the reader reads all the rows matching the SQL statement you specify, passes them through the RecordMapper, and then keeps the resulting objects in memory. That might be a problem if your table has a lot of records. Or perhaps I’ve missed something about how it works.