doron, Thanks!
But in lucene api: For performance reasons it is recommended to open only one
IndexSearcher and use it for all of your searches.
http://lucene.apache.org/java/docs/api/org/apache/lucene/search/IndexSearcher.html
That is a searcher will remain open unless you update the index. So,that will
not
cost much memory and you can get the results whenever you want, and the
performance
will be better, right? (Don't think about state of users in webapp for a while)
Best Regards.
jacky
----- Original Message -----
From: "Doron Cohen" <[EMAIL PROTECTED]>
To: <java-user@lucene.apache.org>
Sent: Wednesday, September 06, 2006 2:06 PM
Subject: Re: Keep hits in results
> Hits is not really a simple container - it references a certain searcher -
> that same searcher that was used to find these hits. When a request for a
> result document is made, the Hits object delegates this request to the
> searcher. So in order to "page through" the results using an existing Hits
> object, that searcher has to remain open. This has a cost - in terms of
> memory, etc. But LIA describes an additional penalty of this approach - for
> a Web search application, keeping the Hits object alive for the case that
> the user would like to see the next "page of results", means "maintaining a
> user state on the server", While this is possible, it is a more complicated
> server side logic to implement, much more complicated than the stateless
> approach where a query is resubmitted for each new page of results. I think
> what LIA really means is - here and also in other cases - let's not
> complicate things (e.g. statefull solution) unless this is really necessary
> (e.g. performance wise in a certain application it is out of the question
> to resubmit a query for every page, etc.)
>
> Hope this helps,
> Doron
>
> "jacky" <[EMAIL PROTECTED]> wrote on 05/09/2006 21:56:53:
>
> > hi,
> > The following words are quoted from "lucene in action":
> > "There are a couple of implementation approaches:
> > 1. Keep the original Hits and IndexSearcher instances available while
> the
> > user is navigating the search results.
> > 2. Requery each time the user navigates to a new page.
> > It turns out that requerying is most often the best solution.
> > Requerying eliminates
> > the need to store per-user state. In a web application, staying stateless
> (no
> > HTTP session) is often desirable. Requerying at first glance seems
> awaste, but
> > Lucene’s blazing speed more than compensates. "
> >
> > I am confused about this paragraph. Since Hits is just a simple
> > container of pointers
> > to ranked search results, it doesn't load from the index all
> > documents that match a query,
> > but only a small portion of them at a time. If we requery, we will
> > get a new hits, why not
> > just keeping the orginal Hits which will not waste much memory.
> >
> >
> >
> > Best Regards.
> > jacky
> >
