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
