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 <bryan_lists@netmeme.org>
wrote:
> On Fri, 2002-10-25 at 00:55, Hookom, Jacob John
> wrote:
>
> > I guess I'm lost as to why CachedRowSet is a zero
> copy?
> > The source code for the basicPortal's still copies
> all the data into another, internal collection.
> >
> > 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
fred_schuh@yahoo.com.br
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>
|