Hello,
Maybe you could just export those data into Excel files (any other format will do), and provide a download link to those file. Those files could be generated lazily, means generate the first time it is requested. I'm just curious, how do people in your company deal with millions of rows of data with their own eyes? On Fri, Apr 9, 2010 at 12:39 PM, Cin Lung <cinl...@gmail.com> wrote: > Hi George, > > Trust me the people in my client's company would see that much of data. It > is needed by the production. > The next best way I can do is to send the resultset object directly to the > JSP, but I would not go to that extent just yet. I am going to either build > a new cache mechanism or use ehcache. The companies where I cater is data > hungry company. > > Thanks > Rendra > > -----Original Message----- > From: George Sexton [mailto:geor...@mhsoftware.com] > Sent: Friday, April 09, 2010 12:50 AM > To: 'Tomcat Users List' > Subject: RE: Tomcat scalability setting - need help please > > Clearly instantiating millions of objects is not a strategy for > scalability. > > You're going to have to re-structure your code to reduce the memory > footprint of each session. > > Why is your result set returning a million rows? No human would want to see > that much data. > > You need to restructure your queries and navigation design so that it > doesn't do this. > > George Sexton > MH Software, Inc. > 303 438-9585 > www.mhsoftware.com > > > > -----Original Message----- > > From: Cin Lung [mailto:cinl...@gmail.com] > > Sent: Thursday, April 08, 2010 10:53 AM > > To: 'Tomcat Users List' > > Subject: RE: Tomcat scalability setting - need help please > > > > Hi George > > > > Your remark is almost correct. What I did is that I store the result > > of the resultset (which can go up to million lines of rows) in a batch > > of Java beans. Then I set the beans to the HTTP Request and pass them > > to the receiving JSP. > > > > But I do remember to return the connection to the pool. I also try to > > kill the statements, result sets, etc by setting them to null. But I > > realize that java might wait for the memory to be cleared by the > > garbage collector. > > > > This goes back to my second problem. If the user closes the browser, > > the request object form the servlet would lost its way to return the > > result. And this will hog the tomcat performance for a while. > > > > Any tips would greatly be appreciated. > > > > TIA > > Rendra > > > > -----Original Message----- > > From: George Sexton [mailto:geor...@mhsoftware.com] > > Sent: Thursday, April 08, 2010 11:42 PM > > To: 'Tomcat Users List' > > Subject: RE: Tomcat scalability setting - need help please > > > > > > > -----Original Message----- > > > From: Pid [mailto:p...@pidster.com] > > > Sent: Thursday, April 08, 2010 8:49 AM > > > To: Tomcat Users List > > > Subject: Re: Tomcat scalability setting - need help please > > > > > > When you run the query in your application how are you doing it, e.g. > > > by > > > calling a stored procedure, or by executing exactly the same SQL > > > statement? > > > > > > > > > Most likely the application is storing result sets on the session. > > > > > > > > George Sexton > > MH Software, Inc. > > 303 438-9585 > > www.mhsoftware.com > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Sincerely yours and Best Regards, Xie Xiaodong
