struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacob Hookom" <hooko...@uwec.edu>
Subject RE: Zero-copy persistence with Struts?
Date Wed, 23 Oct 2002 16:38:09 GMT
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>


Mime
View raw message