On Fri, 25 Oct 2002, Frederico Schuh wrote:
> Date: Fri, 25 Oct 2002 07:01:05 -0700 (PDT) > From: Frederico Schuh <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: Struts Users Mailing List <[EMAIL PROTECTED]> > Subject: RE: Zero-copy persistence with Struts? > > 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. > Conceptually, one can imagine a RowSet implementation that did not copy anything unless you tried to *modify* existing data, at which point it would keep "dirty" copies of the data that was changed. As long as the underlying ResultSet was scrollable, I'd bet you can avoid even the reference copying for the most common scenarios. Of course, any strategy like this still has to deal with the fact that the underlying ResultSet and Statement really do need to be closed (and the connection returned to the pool if you're using one) before the current request completes. Craig -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
