Ian wrote:
> Hi Craig and all:
>
> This must be an area of concern for many people!
>
> If a site has potentially thousands of simultaneous users, each doing a
> general search that potentially has a resultset of thousands of rows - how
> should the paging/scrolling of the resultset be designed? What level of
> detail are people saving in the resultset if they use this approach?
>
> How do the major search engines support page prev/next? Are they really
> storing a session-specific resultset? Even when there are thousands of
> potential rows?
>
> I have seen a reference to one solution that advocates storing a
> second-level key to the resultset and defining a second cursor that can
> reposition at a specific page by using this key - but this seems like a LOT
> of extra work to me, and it doesn't support paging backwards very well.
>
> Thanks for any ideas/experiences,
>
> Ian
>
The details are going to be VERY application specific, but I've seen the following
three general approaches used for stuff like this. Under no circumstances do you
need to keep a result set open for a particular user (and therefore tie up a
database connection):
(1) In-Memory Cache of All Results
This works well if the number of results rows is fairly small, and/or the number of
users is small enough that you have enough memory to cache the results for all of
the current users. This might not be practical on widely used Internet type sites,
but may be VERY practical on specific applications (like on an intranet where the
maximum number of possible users is constrained) -- memory just isn't that
expensive any more.
(2) Re-do the Search Each Time
>From a casual examination of the URLs for several major search engines, this looks
like the strategy they are using:
* Save the query criteria (or the SELECT statement you created,
if accessing a database) in the user's session.
* Include a NEXT and PREVIOUS button on each results page
that includes the "page number" to be displayed. (Obviously,
these would be disabled as appropriate on the first and last
pages of the response).
* If you've executed the complete search once so that you know
how many responses there are, you can play games with hyperlinks
directly to each page number as well:
PageCount = (Total Responses) / (ResponsesPerPage)
rounded up one if there is any remainder.
* When you receive a request from one of these NEXT or PREVIOUS
buttons, use the page number parameter to calculate the number
of results that should be skipped.
* Re-execute the search, skip the calculated number of rows, and
display the next page worth of responses, with new NEXT and
PREVIOUS buttons.
Remember, these engines are not running on single server systems either -- they are
using load balancing to split the load so that any one server can handle an
appropriate fraction of the total volume. The load balancer must send the same
user back to the same server, or the server's application software must support
moving your session data back and forth, for this to work.
(3) Modify the search criteria each time
As in case (2), the query criteria and/or the SELECT statement you are using is
saved in the user's session. However, the criteria are modified so that you only
select the rows you want, instead of having to skip previous ones. This isn't
always going to be possible, but can be done in many scenarios.
An example of using this approach would be where you are listing customers in
account number sequence. You could save the account number of the last account
displayed on the previous page, and add "and (account_id > xxx)" to the end of the
SELECT statement for this page. In essence, you are having the database do the
skipping that case (2) makes you do yourself.
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
