You only want a single IndexSearcher for EVERY user searching an index.
IndexAccessor will manage this for you. The only reason you might have
more than one IndexSearcher is if you have more than one index to search
or some additional MultiSearchers. You always want ONE IndexSearcher,
ONE IndexWriter, and ONE IndexReader for each index. You can only do
write operations with one Writer or writing Reader at a time
though...IndexAccessor enforces the right rules for this: i.e. if you
ask for a writing Reader and the IndexWriter for that index is already
out, you won't get the writing Reader until that IndexWriter has been
returned to IndexAcessor.
- Mark
Mohammad Norouzi wrote:
Hello Mark,
there is something vague for me about the Lucene-indexAccessor you
created
and my problem.
as I see your codes, you create IndexSearcher and put it into a Map
and the
only thing that separate them is the Similarity the have. so if say 1000
users with different Similarity connect to my application there will
be 1000
IndexSearcher with their own internal Reader.
now, in my case, I have an IndexResultSet just like java.sql.ResultSet
which
it contains a Hits. so a user may go forward or backward through the
Hits'
documents and actually every user are doing this job.
to do so, I have to find the Similarity that a user working with it
and find
the right IndexSearcher in order to support pagination for her. is this
right? I mean can I trust to Similarity to find the right IndexReader
that a
user have used it before?
another question is, how about I have one IndexReader for all my
IndexSearcher and manage them simultaneously to access that single
Reader.?
thank you very much in advance
On 2/22/07, Mark Miller <[EMAIL PROTECTED]> wrote:
I would not do this from scratch...if you are interested in Solr go that
route else I would build off
http://issues.apache.org/jira/browse/LUCENE-390
- Mark
Mohammad Norouzi wrote:
> Hi all,
> I am going to build a Searcher pooling. if any one has experience on
> this, I
> would be glad to hear his/her recommendation and suggestion. I want to
> know
> what issues I should be apply. considering I am going to use this on a
> web
> application with many user sessions.
>
> thank you very much in advance.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
