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>