Why not look at an OJB/Castor implementation? Through Object caching and identity referencing, there are (in near all cases) only a single instance of any object in memory, plus the addition of hands-free lazy loading of collections/relations, OJB is REALLY appealing for web applications.
-Jacob | -----Original Message----- | From: Miller, Jason [mailto:jmiller@;ostglobal.com] | Sent: Wednesday, October 23, 2002 11:13 AM | To: 'Struts Users Mailing List' | Subject: RE: Zero-copy persistence with Struts? | | 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 | > -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
