Yuki Tanabe wrote:
> Thanks for your help!
>
> The problem with just returning the result page in a single.html file is that
> the it could contain anything up to 1000 rows, and I am worried that this would
> take ages to load. What if what the user actually needed to see was in the first
> 100 rows? Ideally, I would like to immitate something done, for example, by the
> Amazon.com site.
>
> After having some of your advices I am planning to do the following:
> 1. Generate appropriate number of pages according to the query nad store them as
> .html files.
>
> 2. Once the session with the current user is over, delete these pages.
>
As others have suggested, storing the generated pages in your session, instead of
in files, takes care of the delete issue. It also avoids any need to create
temporary filenames that are unique (and the associated overhead of all the file
I/O). But, see below for a different perspective.
>
> I'm still new to this stuff so I'll have to figure out how to do part 2, but
> please commment on my overall approach.
>
When thinking about the approach you are suggesting (pre-generate all the pages),
let's take your scenario -- the stuff the user really wanted was in the first 100
rows. Doesn't that mean that any effort you expended to create the remaining pages
was "wasted"? Wouldn't it be better to only generate as much as the user needs?
Here's a set of possible design patterns for what I like to call the "display the
search results" problem. I've used nearly all of these approaches, depending on
the particular application requirement, so there is no one right answer:
(1) ALL IN ONE PAGE
Display all the results in a single (probably pretty long) page. This works great
when you know for a fact that the number of responses is pretty limited, or when
the user is likely to want a printed copy of the results (it's much more convenient
to print once instead of once per page). Even if you use one of the other design
patterns for normal use, you might consider providing an option for the "all in one
page" version.
(2) PRE-GENERATE THE PAGES
Your suggested approach, but storing the HTML as strings in the user's session.
The disadvantages I see are:
* Time it takes to pre-generate all the pages
before showing the first result.
* Memory space occupied by all the HTML
(see pattern 3 for a similar alternative).
* The fact that some number of these pages
will never be referenced, so any effort
expended to create them is wasted.
Storing in disk files solves the memory space issue, at the expense of an even
bigger performance hit.
(3) STORE ENTIRE RESULT SET IN SESSION
AND DYNAMICALLY GENERATE THE PAGES
If you can store the results of your query as a Java collection object of some sort
in the user's session, then you know exactly how many pages you will need, and you
can create them on the fly. As you create a page of the response, you would add
"Previous" and "Next" links at the bottom, which would pass in a parameter that
says which page number you want. The page generator uses that to know how many
rows to skip before starting to generate the currently requested page.
If you are reading data from a database (via JDBC) to create your response, it is
tempting to just store the java.sql.ResultSet containing your results in the
session. This is going to cause scalability problems, however, because it requires
leaving the corresponding statement open across multiple HTTP queries (and can
cause things like running out of database cursors). You are better off copying the
data into some "disconnected" collection class.
(4) RERUN THE QUERY EACH TIME
In many cases, the number of rows you need to retrieve are so large that you cannot
afford the memory space needed to keep them all, as is required for pattern (3).
An alternative is to just rerun the query for each request, skipping the
appropriate number of rows before starting to display the results based on the
requested page number. You may need to run the query completely the first time, to
know how many rows there are. You also need to be aware that the actual results
might change between requests due to other people running applications.
A variation on this theme is to actually modify the query itself to skip the rows
you do not want, instead of having to read them and skip them yourself. When this
is practical, it can improve performance.
Search engines like Yahoo and Google use a pattern somewhat like #4, but against a
very optimized database that indexes words against referenced pages.
>
> Any help is greatly appreciated!
>
> Regards,
>
> Yuki
>
Craig McClanahan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
