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 Fri, 25 Oct 2002 13:46:29 GMT
That's the thing though, granted objects are passed by reference, but,
with cached rowset, each call to the db will result in the creation of a
new set of container objects to hold all of the fields (container for
all rows, a container for each column of that row).  The only real
resolve to this issue is to create a variation of the Flyweight pattern
where we ID the data from the resultset to prevent new'ing container
objects, much like OJB's ObjectCache class.  I think there was a
framework started in basicPortal to handler this, but I'm not sure.  I
tried to grab the source for it all, but it was still missing java
files.

-jacob

| -----Original Message-----
| From: Bryan Field-Elliot [mailto:bryan_lists@netmeme.org]
| Sent: Friday, October 25, 2002 8:39 AM
| To: Struts Users Mailing List
| Subject: RE: Zero-copy persistence with Struts?
| 
| 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


--
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