tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Price <>
Subject Re: [off topic] - passing a ResultSet from a servlet to a JSP
Date Tue, 29 Apr 2003 21:18:09 GMT wrote:
> Hi Shapira,
> I've had the same issue, so I'm tempted to jump into this discussion.
> This technique is fairly ok, if the resultset is expected to be approx. 
> 1000 records.
> If you have 10.000 records with size of 100 Bytes each, you have 1 MB 
> sitting in request.setAttribute() and passed to the JSP. This 1 MB gets 
> garbage collected some seconds later by the JVM.
> I tried this technique with an even bigger resultset of 50.000 records, 
> which is likely to slow down Tomcat and require lots of memory if users 
> simultaneously surf around with this size of recordsets. I was able to 
> capture more than 50 MB easily simple by reloading a page in MS IE 
> repeatedly.
> The only way I found around this so far is to allow navigation across the 
> resultset, which shifts the problem to the server/database system to allow 
> for fetching the records using LIMIT-clause in mySQL for example or to use 
> cursors to navigate in the resultsets. This works fairly good, but only if 
> users are satisfied having to browse inside the lists. 
> Additionally, the database server has to work quite optimized for this 
> LIMIT-statement, as it is re-calculated for each request. Does anybody 
> have a better solution for this (cursors? EJBs??).
> I haven't yet found a fine solution to this problem, maybe others have?

Hmmm... 10,000 records?  It sounds like you are describing a situation 
similar to a search interface which displays matches.  You have also 
described a need to persist these matches from page to page (I assume 
this, judging from your desire to put the resultSet into the session).

Why not just fetch the number of records that you intend to display on a 
given page, and pass the offset of the last fetched record?  This way, 
on the first page you can display records 1-20, and you pass "20" to the 
second page (via the session, querystring, or hidden form field).  On 
the next page, you simply display 20 records starting with the offset + 
1 (21), so you end up with records 21-40.

This way you aren't stuck with a huge 1MB object for each user who is 
using your application, just smaller objects which you can allow to be 
garbage collected after they are used to display the results.

Unless you really are performing operations on 10,000 objects and need 
to do this across multiple HTTP requests....


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message