Craig, u done it again, where was that poor fellow who splitted some nonsense abt u are
u hearing this reply young chap???.
Excellent piece Craig,
Thanks for ur knowledge sharing we learned a lot,
Srini
"Craig R. McClanahan" wrote:
> 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
___________________________________________________________________________
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
