Zero-copy persistence with Struts?

[Bryan Field-Elliot <br...@netmeme.org>]

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

Re: Zero-copy persistence with Struts?

[Bryan Field-Elliot <br...@netmeme.org>]

Thanks, I'll take a look.

I've never even used RowSet before... My trusty O'Reilly JDBC book
devotes a whopping 2 pages to RowSet which I conveniently overlooked.
I'll take a look at RowSet and then the CachedRowSet extension...

Bryan


On Wed, 2002-10-23 at 12:09, Eddie Bush wrote:

> If you're set on zero-copy, CachedRowSet is probably the best way to go. 
>  There is an OS implementation on sourceforge, I believe.  Vic uses it 
> in basicPortal - that is his approach as well.
> 
> Personally, I use OJB.  If you're trying to cut out all the "overhead" 
> you can CachedRowSet would probably be the way to go though 
> (minimalistic).  One of the neat things about the CRS approach is that 
> you can actually ask the RowSet to update itself, and provide it a 
> connection it will use to do so - so you can have transactional control 
> over it.  At the same time, being cached (disconnected), it does not 
> require you to keep anything "open" (connection/statement/<insert JDBC 
> thing here>), so you can follow better, more straight-forward practices 
> by using it.
> 
> -- 
> Eddie Bush
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
-- 
Bryan Field-Elliot <br...@netmeme.org>

Re: Zero-copy persistence with Struts?

[Eddie Bush <ek...@swbell.net>]

If you're set on zero-copy, CachedRowSet is probably the best way to go. 
 There is an OS implementation on sourceforge, I believe.  Vic uses it 
in basicPortal - that is his approach as well.

Personally, I use OJB.  If you're trying to cut out all the "overhead" 
you can CachedRowSet would probably be the way to go though 
(minimalistic).  One of the neat things about the CRS approach is that 
you can actually ask the RowSet to update itself, and provide it a 
connection it will use to do so - so you can have transactional control 
over it.  At the same time, being cached (disconnected), it does not 
require you to keep anything "open" (connection/statement/<insert JDBC 
thing here>), so you can follow better, more straight-forward practices 
by using it.

-- 
Eddie Bush



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Zero-copy persistence with Struts?

["V. Cekvenich" <vi...@users.sourceforge.net>]

Look at basicPortal.sf.net, we use rowSet, not resultset.
.V

Bryan Field-Elliot wrote:
> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>