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. Isn't that copying the data or did I miss the definition of zero copy? 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. Please catch me if I'm mistaken. Regards, Jacob
-----Original Message-----
From: Frederico Schuh [mailto:fred_schuh@;yahoo.com.br]
Sent: Fri 10/25/2002 1:41 AM
To: Struts Users Mailing List
Cc:
Subject: RE: Zero-copy persistence with Struts?
Though I agree with the CachedRowSet solution, I don't
think using a ResultSet is bad at all. If you can find
a way to wrap it around an interface like you are
proposing, it can be cleaner to the JSP page and will
be more memory efficient than using a CachedRowSet,
and thus it will be more scalable. It will probably be
slower to iterate through, due to the fact that it
maintains an open connection and makes several calls
to fetch data through the network, but memory is
usually a more critical resource in a server.
If you plan to work with huge lists of entries, I
think you should consider using a ResultSet. The
disconnected CachedRowSet sounds nice, but if you have
a high traffic of users, I believe your server might
be very likely to fail serving the requests due to the
high memory usage.
I've never done this actually, but I think it would
perform well. Any opinions on this?
On Wed, 2002-10-23 at 12:09, Eddie Bush wrote:
> If you're set on zero-copy, CachedRowSet is probably
the best way to go.
> There is an OS implementation on sourceforge, I
believe. Vic uses it
> in basicPortal - that is his approach as well.
>
> Personally, I use OJB. If you're trying to cut out
all the "overhead"
> you can CachedRowSet would probably be the way to go
though
> (minimalistic). One of the neat things about the CRS
approach is that
> you can actually ask the RowSet to update itself,
and provide it a
> connection it will use to do so - so you can have
transactional control
> over it. At the same time, being cached
(disconnected), it does not
> require you to keep anything "open"
(connection/statement/<insert JDBC
> thing here>), so you can follow better, more
straight-forward practices
> by using it.
>
> --
> Eddie Bush
--- "Miller, Jason" <[EMAIL PROTECTED]> wrote:
> I do something similar to what you are proposing, so
> far as the
> ResultSet-to-the-view bit goes. I have a wrapper
> class that adapts an
> Iterator interface to anything you need.
>
> So far as closing the resources go, I ended up
> coding in a requirement that
> the ResultSet only contain the data that is to be
> displayed. This isn't as
> much of a problem as one would think, since
> normally, its a waste of time to
> get 1000 rows from a database when only 50 are being
> displayed anyway. It
> would also be trivial to extend the class to
> configure it to display X
> number of rows and then close.
>
> The wrapper is not specific to ResultSets - it can
> wrap any source of data
> so long as a subclass is defined to transform the
> data.
>
> I can send you what I have, if you are interested,
> or post it somehow. At
> least it may give you a starting point, and it will
> certainly explain what I
> mean better than I have done here.
>
> Jason
>
> > -----Original Message-----
> > From: Bryan Field-Elliot
> [mailto:bryan_lists@;netmeme.org]
> > Sent: Tuesday, October 22, 2002 10:36 PM
> > To: Struts Users Mailing List
> > Subject: Zero-copy persistence with Struts?
> >
> >
> > I'm banging my brain against the sides of my skull
> trying to
> > think of a
> > way to do zero-copy JDBC persistence with Struts.
> >
> > What I mean by zero-copy is, basically, pass as
> much "raw data" as
> > possible between the Model layer and the View
> layer. In
> > pragmatic terms,
> > this probably means taking a JDBC ResultSet in the
> Model layer,
> > decorating it somehow (e.g. wrapping it in a
> DynaBean, or otherwise),
> > and setting it into the Request attribute context,
> where the JSP page
> > can iterate through and display it.
> >
> > Why bother? Performance.
> >
> > So here's the catch... if I insert the ResultSet
> into the request
> > context, then somewhere later I need to close the
> ResultSet, and
> > probably also the Statement which produced it and
> possibly even the
> > Connection which was queried in the first place.
> It wouldn't
> > make sense
> > from a design standpoint to put this plumbing in
> each JSP page.
> >
> > My thinking is to build a Filter (Servlet 2.3)
> which, after all Model
> > and View classes are called (e.g. Struts actions
> and JSP pages), close
> > all the ResultSets, Statements, etc. This seems a
> little complex but
> > it's the best pattern I can come up with. I was
> hoping for
> > some (expert)
> > opinions on this approach.
> >
> > The basic flow would be:
> >
> > 1. Struts Action does the following:
> > 1a. grabs a connection from the pool
> > 1b. create a Statement (or PreparedStatement),
> do the JDBC work,
> > obtain a ResultSet
> > 1c. Decorate the ResultSet as needed (e.g. wrap
> it inside a
> > ResultSetDynaClass)
> > 1d. Push the original Connection, Statement,
> and ResultSet onto a
> > request context "stack" of some kind (with an
> agreed-upon key name).
> > 2. JSP page does the following:
> > 2a. Iterate through the ResultSet (or it's
> wrapper) as if it were a
> > standard collection of standard beans.
> > 3. Filter does the following cleanup:
> > 3a. Retrieve the "stack" of open JDBC
> primitives from the request
> > context.
> > 3b. Close them all.
> >
> > This seems to achieve a nice level of
> zero-copyness without bothering
> > the JSP page with messy plumbing details.
> Comments?
> >
> > Thanks,
> > Bryan
> >
>
=====
----------------------------------------
Frederico Ferro Schuh
[EMAIL PROTECTED]
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>
<<winmail.dat>>
-- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
