Process results from resultset vs from data structure

[Mike Ottinger]

Hi Guys,

I'm working with a DB2 backend that returns, not an incredible amount of data, but somewhat sizable(100+ rows x 28 columns). The issue is the data needs to be processed in a pretty complex fashion. The initial design is to run through the resultset once and handle the processing that way. This lends towards an awkward design, as it's sometimes necessary to go back to previously processed rows to determine certain values. So the design gets ugly with loop variables and flags all over the place. And some columns from the call are used throughout every aspect of the processing, yet they're never taken off the resultset. I've decided to look into redesigning it so that the call is executed, the resultset is stored in a collection of beans, thus processing is more straight-forward, because the entire results are made available in an internal data structure. This collection will be iterated through a number of times, but I still feel this is a faster solution. What difference in performance can be gathered between a call to a resultset, versus a call to a getter in a bean, within a collection? Thanks, and sorry for the long-winded question

-M

[Roger Chung-Wee]

As you would want to close JDBC objects as soon as possible, it looks to me as if you need a disconnected RowSet. This means that the RowSet gets the data from the data source and its connection is then closed. You can then retrieve the data from the RowSet without tieing up connections and cursors.

[Jeff Albertson]

I've never seen the advantage of a disconnected row set versus a collection of beans, beyond the quick and dirty aspect of not needing to code the bean class (although you usually need to code it eventually in any case). Why go for the row set? I'm thinking POJO beans a la Hibernate here.

[Mike Ottinger]

Hi Guys,

Thanks for the replies. I'm not familiar enough with Hibernate to know whether it would be a viable solution for what I'm working on. My data doesn't need to persist for too long. I read it in, generate a rather complicated xml structure off of it, then send it on its way through a JMS queue. I always imagined Hibernate as a persistence mechanism that employs POJO rather than db related stuff. I think I can gather from the replies that the idea of moving my data into a POJO structure is the better way to go(?). Thanks.