Sorry for getting in late on this one. "I was just at Google, and Google's an all-MySQL shop. Why did they do it? Because they looked at DB2 and it was expensive and it didn't offer any added value." - Jonathan Schwartz
Here's the full story: http://news.com.com/2008-1082-947510.html James Mitchell Software Engineer\Struts Evangelist Struts-Atlanta, the "Open Minded Developer Network" http://www.open-tools.org/struts-atlanta > From: Bartley, Chris P > Subject: RE: [OT] RE: Struts and Large ResultSet > Date: Thu, 05 Sep 2002 07:01:34 -0700 > > -------------------------------------------------------------------------- ------ > > I can't provide any explanation for how they've implemented things, but one > thing that might be interesting is that all the hits don't appear be > viewable. For kicks I searched on "computer" and was only able to browse > through the first 995 of the 60.8 million results. > > chris > > > -----Original Message----- > > From: Mazza, Glen R, PERSCOM [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, September 05, 2002 9:17 AM > > To: 'Struts Users Mailing List' > > Subject: [OT] RE: Struts and Large ResultSet > > > > > > Google would seem to be a very good example of how to handle > > extremely large > > result sets. A search on "America", for example, returned > > 36.2 million rows > > kept server-side, which the browser can quickly requery to > > get the results, > > 10 or so rows at a time. > > > > Can anyone surmise Google's probable approach to this? Do > > they actually > > retain DB cursors on the server side to query an additional > > 10 rows at a > > time--but given their very fast response time, I suspect they > > may be using > > some other form of non-database cursor--I'm unsure if search > > engines even > > use databases to return their result sets. > > > > Thanks, > > Glen > > > > > > ------------------------------------------------- > > > > Changing data will happen. I see this kinda thing happen on > > google. You to a > > page and then when the results update the page 5 is different > > than it was > > just a minute ago on the same query. It's kinda the way > > things are I think. > > The only way to avoid this is to keep the ResultSet open and > > updated from > > the database. This is not a very good solution for high traffic sites. > > > > Brandon > > > > -----Original Message----- > > From: John Owen [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, August 22, 2002 9:50 AM > > To: Struts Users Mailing List > > Subject: Re: Struts and Large ResultSet > > > > > > I suggested using the ArrayList for providing a read-only view of the > > current state of the database. If something changes, your > > view would remain > > constant until you performed another query. If I were to provide > > functionality for an item in the ArrayList, such as update, I > > would make > > sure the system retrieved the latest copy of the item in question. > > > > I would not suggest keeping a ResultSet of that size in the > > user session. ;) > > I also would suggest determining if you really need to query > > 100,000 records > > at once. If so, your J2EE container, application server or > > client machine > > has to be able to handle that much information. If you devise > > cursors using > > a row limit (like rowcount, or is it rowid/rownum?) or some > > clever query > > mechanism, you can pull back data in small, but meaningful groups. > > Query-specific applications are database-dependent. I could > > devise something > > for Oracle 8.17 using cursors and using the limit > > functionality, but it > > would not apply to mysql and other databases. > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
