Couple of thoughts: 1. Can you get and unique ID of the record(s) and store it somewhere (users session) ? Pageing through would be easy (although if you have to store couple of 1000 ids, it's not pretty) 2nd option maybe ?
2. Or is there a certain order by which this ResultSet is ordered by ( SELECT blah from BLAHBLAH ORDER BY blah ) ? In this case you can store the ID of the first & last record displayed and then on the "next" & "previous" actions, you'd use these to go up and down ( so to speak ). Jf Michael Lee wrote: >Actually this is a very valid topic, one which I'm struggling with now. I >use scrollable cursors when I set up my statement and setFetchSize and do >ResultSet.absolute() to go to the row that the 'NEXT' button sent. Is this >the right path? In struts I'll most likely send a >strutsAction.do&firstRow=50?listSize=25 or something on my submits but as >anyone done pagination on large sets like this? I do a query every time they >click next. I don't think this is the best idea but I don't want to keep a >result set sitting around... >any idea? Am I on the right path? >thanks, >Mike > > >----- Original Message ----- >From: "Matt Veitas" <[EMAIL PROTECTED]> >To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >Sent: Thursday, September 05, 2002 10:28 AM >Subject: Re: [OT] RE: Struts and Large ResultSet > > > > >>You can be assured they have lots and lots of money invested in huge >>server farms and other hardware!!!! >> >>Mazza, Glen R, PERSCOM wrote: >> >> >> >>>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. >>> >>>----- Original Message ----- >>>From: "Gus Delgado" <[EMAIL PROTECTED]> >>>To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >>>Sent: Thursday, August 22, 2002 10:17 AM >>>Subject: Re: Struts and Large ResultSet >>> >>> >>> >>> >>> >>> >>>>The only problem with returning so much data is that your ArrayList and >>>>the database can get out of sink if some else updates one of those >>>> >>>> >>>> >>>> >>>records. >>> >>> >>> >>> >>>>Ashish Kulkarni wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi >>>>>do u keep this Object in the user session??? >>>>>if so, how does it affect the perforamce?? >>>>>Ashish >>>>>John Owen wrote:Irregardless of struts, I would suggest storing the >>>>> >>>>> >>>>> >>>>> >>>ResultSet in an object >>> >>> >>> >>> >>>>>and then maniuplating the bean (for viewing) through an Action class. I >>>>>typically store data from a ResultSet in an object and put the object >>>>> >>>>> >>>>> >>>>> >>>into a >>> >>> >>> >>> >>>>>collection such as an ArrayList. >>>>> >>>>>Hope this helps, >>>>> >>>>>John >>>>>----- Original Message ----- >>>>>From: "Ashish Kulkarni" >>>>>To: "Struts Users Mailing List" >>>>>Sent: Thursday, August 22, 2002 9:29 AM >>>>>Subject: Struts and Large ResultSet >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Hi, >>>>>> >>>>>>Has any one handled lasgre result set using struts, like my sql query >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>returns ablut 100,000 records but i want to show only 20 records per >>>>> >>>>> >>>>> >>>>> >>>page, >>> >>> >>> >>> >>>>>and then when the user clicks next, want to show the next 20 .. >>>>> >>>>> >>>>> >>>>> >>>>> >>>-- >>>To unsubscribe, e-mail: >>> >>> ><mailto:[EMAIL PROTECTED]> > > >>>For additional commands, e-mail: >>> >>> ><mailto:[EMAIL PROTECTED]> > > >>> >>> >>> >>> >>> >>-- >>To unsubscribe, e-mail: >> >> ><mailto:[EMAIL PROTECTED]> > > >>For additional commands, e-mail: >> >> ><mailto:[EMAIL PROTECTED]> > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- *Phase 2 Development* 825 N. Broadway, Suite 420 Oklahoma City, OK 73102 *Jano Fetyko* /Script Fighter/ [EMAIL PROTECTED] (o) 405.232.4545 ext 231 (f) 405.232.4550 http://www.phase2online.com "Oklahoma City's fastest growing web development company" -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> tsdok -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
