Return-Path: <kevin@susa.net>
Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list tomcat-user@jakarta.apache.org
Received: (qmail 88111 invoked from network); 13 Feb 2001 18:30:44 -0000
Received: from kakapo.susa.net (212.88.54.250)
  by h31.sny.collab.net with SMTP; 13 Feb 2001 18:30:44 -0000
Received: from kevin (helo=localhost)
	by kakapo.susa.net with local-esmtp (Exim 3.03 #1)
	id 14SkBR-0007D4-00
	for tomcat-user@jakarta.apache.org; Tue, 13 Feb 2001 18:28:13 +0000
Date: Tue, 13 Feb 2001 18:28:13 +0000 (GMT)
From: Kevin Sangeelee <kevin@susa.net>
To: tomcat-user@jakarta.apache.org
Subject: RE: search display problem
In-Reply-To: <A1C69E9A4D29D311AFE000A024CA0B0B141397@snax.thwt.com>
Message-ID: <Pine.LNX.4.10.10102131757200.27600-100000@kakapo.susa.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

On Tue, 13 Feb 2001, Randy Layman wrote:

> 	You could suck in all of the resultset into some data holding object
> (List of basically C-style structs) and store this in the session.  Then use
> a current page variable to select the correct rows.  This would probably
> waste lots of memory but would limit the number of database accesses.

I agree it's off topic, but then what would Tomcat be without a DBMS?
So...

An alternative to your idea is only to hold the primary key column in an
array within a session bean, and pages could be accessed using array
chunks of <pagesize> using sql something like: -

	SELECT <columns> FROM TABLE WHERE mykey IN (array[i],
		array[i+1],...) ORDER BY <whatever>;

for each new page. Also, memory usage per session is easy to estimate for
array if integer primary keys.