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.
No it does not.  CVS will be up, else I would link you.
Pseudo code is soemthing like this:

getNameX () {

getDAO().getRowSet().getString("namex");

}

and same on setter. See it just uses a pointer to rowset.

I code it as
getNameX () {
getProperty("namex");
}
but it is same as above.


// Isn't that copying the data or did I miss the
definition of zero copy?
That would be, but data goes to rowset and stays there (hence the name of diesconected row set). For high loads, I have clients with 40,000 and 10,000 concurent Struts users, you can't copy or do new this or new that. That would double the number of servers my client needs.

hth, .V

// With OJB, objects are placed in a cache, so
if you are querying the db, and a row is returned as an object, it's first fetched from the cache-- zero copy. With each request with a CachedRowSet, aren't you instantating just as many objects each time, granted you aren't wrapping the columns in an object, but you are still wrapping them in something like an Object[] or a Map (gasp). Even if you were to re-use the CachedRowSet as part of an action at the application scope, you would be needing to load all the data for every user to be able to filter over as you push it to the jsp.
To cache rowsets, you can turn on Poolmans caching, so no SQL Select firest, if the rowset is there already.

Please catch me if I'm mistaken.

Regards,
Jacob





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

Reply via email to