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
