Re: Zero-copy persistence with Struts?

[V. Cekvenich]

Craig R. McClanahan wrote:

On Fri, 25 Oct 2002, Frederico Schuh wrote:

Date: Fri, 25 Oct 2002 07:01:05 -0700 (PDT)
From: Frederico Schuh <[EMAIL PROTECTED]>
Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
To: Struts Users Mailing List <[EMAIL PROTECTED]>
Subject: RE: Zero-copy persistence with Struts?

The CachedRowSet has to perform copying of data, it
cannot keep track of references only . The ResultSet
has a small volatile buffer that gets overwritten as
it is iterated over. So this means that if the
CachedRowSet stored only pointers, it would point to
the most recent rows being fetched from the ResultSet
at the moment.
One of them has to perform a copy to a buffer (I
suspect the rs.getObject() method might create a
copy), though I am more inclined to believe the
CachedRowSet is responsible for it.
For memory efficient operations, ResultSet is probably
the way to go.

Conceptually, one can imagine a RowSet implementation that did not copy
anything unless you tried to *modify* existing data, at which point it
would keep "dirty" copies of the data that was changed.  As long as the
underlying ResultSet was scrollable, I'd bet you can avoid even the
reference copying for the most common scenarios.

Of course, any strategy like this still has to deal with the fact that the
underlying ResultSet and Statement really do need to be closed (and the
connection returned to the pool if you're using one) before the current
request completes.

Now that CVS is back up:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/basicportal_07/src/basicWebLib/org/commons/DAO/BasicDAOImpl.java?rev=1.2&content-type=text/vnd.viewcvs-markup
Above does close the RowSet. RowSet is a bean, and can be new() and GC out of scope, unlike ResultSet. My argument is that it is harder for a new programer to close a ResultSet (finaly, nested).
On acceptchanges and execute one can pass the connection, which is only used for a split second.
The point is that the data is available even after the connection is closed. This is as close to Zero copy as one can get. Also RowSet implementations are inter changeable.
Pseudo code:
String getX () {
(String)getDAO().getRowSet().getProperty("x"); }

So DAO on sourceForge is a good example of minimal copying.

Also, it does acceptchanges(), so it auto generates inserts and updates. This is similar to DynaResultSet iterator, except that DynaResulSet does not update or insert. I am looking at SQL in Commons-Sanbox, which does inserts/updates via DynaBeans, if a DynaBeans implementation (of the Dyna Iterfaces) can use a RowSet with some other goodies, if this improves the DAO design for good practices example app.
ie. Bus.Bean is DynaBean and does CRUD via Reflection, and it was disconected. (I know, I know; but it makes sense sometimes, copy and new() creates some load on GC)

.V

Craig

--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>