I do something similar to what you are proposing, so far as the ResultSet-to-the-view bit goes. I have a wrapper class that adapts an Iterator interface to anything you need.
So far as closing the resources go, I ended up coding in a requirement that the ResultSet only contain the data that is to be displayed. This isn't as much of a problem as one would think, since normally, its a waste of time to get 1000 rows from a database when only 50 are being displayed anyway. It would also be trivial to extend the class to configure it to display X number of rows and then close. The wrapper is not specific to ResultSets - it can wrap any source of data so long as a subclass is defined to transform the data. I can send you what I have, if you are interested, or post it somehow. At least it may give you a starting point, and it will certainly explain what I mean better than I have done here. Jason > -----Original Message----- > From: Bryan Field-Elliot [mailto:bryan_lists@;netmeme.org] > Sent: Tuesday, October 22, 2002 10:36 PM > To: Struts Users Mailing List > Subject: Zero-copy persistence with Struts? > > > I'm banging my brain against the sides of my skull trying to > think of a > way to do zero-copy JDBC persistence with Struts. > > What I mean by zero-copy is, basically, pass as much "raw data" as > possible between the Model layer and the View layer. In > pragmatic terms, > this probably means taking a JDBC ResultSet in the Model layer, > decorating it somehow (e.g. wrapping it in a DynaBean, or otherwise), > and setting it into the Request attribute context, where the JSP page > can iterate through and display it. > > Why bother? Performance. > > So here's the catch... if I insert the ResultSet into the request > context, then somewhere later I need to close the ResultSet, and > probably also the Statement which produced it and possibly even the > Connection which was queried in the first place. It wouldn't > make sense > from a design standpoint to put this plumbing in each JSP page. > > My thinking is to build a Filter (Servlet 2.3) which, after all Model > and View classes are called (e.g. Struts actions and JSP pages), close > all the ResultSets, Statements, etc. This seems a little complex but > it's the best pattern I can come up with. I was hoping for > some (expert) > opinions on this approach. > > The basic flow would be: > > 1. Struts Action does the following: > 1a. grabs a connection from the pool > 1b. create a Statement (or PreparedStatement), do the JDBC work, > obtain a ResultSet > 1c. Decorate the ResultSet as needed (e.g. wrap it inside a > ResultSetDynaClass) > 1d. Push the original Connection, Statement, and ResultSet onto a > request context "stack" of some kind (with an agreed-upon key name). > 2. JSP page does the following: > 2a. Iterate through the ResultSet (or it's wrapper) as if it were a > standard collection of standard beans. > 3. Filter does the following cleanup: > 3a. Retrieve the "stack" of open JDBC primitives from the request > context. > 3b. Close them all. > > This seems to achieve a nice level of zero-copyness without bothering > the JSP page with messy plumbing details. Comments? > > Thanks, > Bryan >
