Open Source RowSet is at jxUtil on Sourceforge, easy to look at.
Also Oracle has RowSet as optional download to the JDBC (it is not a part of regular Oracle JDBC)
I found it to be fastest, easiest. My favorite part is that RowSet can use any SQL command with any SQL hints, etc. The slow part of a Web App is typically DB access for larger sites.
.V
Frederico Schuh wrote:
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.--- Bryan Field-Elliot <[EMAIL PROTECTED]> wrote:On Fri, 2002-10-25 at 00:55, Hookom, Jacob John wrote:copy?I guess I'm lost as to why CachedRowSet is a zero
all the data into another, internal collection.The source code for the basicPortal's still copies
Regards, Jacob
Here's how my thinking has evolved since I opened
this thread a couple
of days ago.
If you're working in C/C++, zero-copy has a very
black-and-white quality
to it. However in Java, there's something of a
middle position, and that
is reference copying. Creating multiple references
to an object already
created, while certainly more expensive than not, is
still not really
copying the data. No object's are "new"'d, and
little impact is made
upon the garbage collector. That is to say (if I
understand the JVM
correctly), references going in and out of scope DO
impact the garbage
collector (in that they may trigger other objects to
be gc'd), but they
are not themselves gc'd. A lessened impact, but
greater than zero.
I see three possible scenarios.
1. If we assume that the "raw" data is in the
ResultSet primitive, then
the shortest, most optimal route, is to get the
ResultSet all the way to
the View (JSP pages). It can be wrapped inside
another class (a
decorator) to make it more bean-like or otherwise
more JSP friendly.
This minimizes memory use and even reference use.
2. The next best thing is a wrapper object which
iterates through the
ResultSet, and copies all the rows and columns, by
REFERENCE, to a
different kind of collection. I suspect that this is
what CachedRowSet
does. Note that it isn't really copying the data
(e.g. no ".clone()"'s
are going on, although someone correct me if I'mw
rong), but instead
it's copying the references returned by each
ResultSet.getObject() call.
3. The worst thing would be a mechanism which
literally copies the data,
and not just the references to the data, using
clone() or something. I
can't imagine any of the persistence frameworks
actually do this.
So the question becomes - does, or does not,
reference copying qualify
as "zero-copy" as originally defined? I guess that's
a larger issue,
don't really want to tie up this Struts list with a
debate like that.
Actually - the more I look at it - scenarios #1 and
#2 are probably
equivalent in terms of use of references. Without
going into too much
detail - a decorator class which delegates the
"gets" and "sets" to an
private object (ResultSet in scenario #1) is
probably doing just as much
reference cloning as a wrapper which iterates
through all rows at
startup and copies the references into a private
collection (scenario
#2).
It may be that CachedRowSet is as good as it gets.
Bryan
===== ---------------------------------------- Frederico Ferro Schuh [EMAIL PROTECTED] ICQ: 20486081 __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
-- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
