My two cents:
Lucene often offers the least common denominator...for example: out of
the box, Lucene best handles either a single user / single thread
experience or a mostly 'read only' experience. I believe that the main
reason for this is that it serves the greatest variety uses. You can,
and people have, put a layer on top of Lucene's simple abstractions to
handle a very interactive index that must serve many threads.
One of your best options is Solr. Solr (among many, many other things)
handles opening and closing Readers and Searchers for you in order to
maintain a lively index. Throw in all of the caching, distribution, and
schema options and its hard to argue that you shouldn't always use this
for a multi user interactive index.
Another option is: http://issues.apache.org/jira/browse/LUCENE-390
I don't think this option has gotten the attention it deserves. If you
are not interested in Solr, or your requirements are not quite as steep,
390 is a great tool. 390 will correctly manage Directories, Readers,
Writers, and Searchers in a way that allows any index modifications to
trigger the reopening of Readers. Making sure there is only one Writer
and so forth is handled for you. There are a lot of enhancements you can
make to this cool little issue and it is also very easy to integrate
into a current solution.
- Mark
Doron Cohen wrote:
Indeed, having to re-open a searcher/reader in order for searches
to reflect index modification, can sometimes not best fit with the
logic of a certain application.
But see the features made possible with this design:
(+) searches do not feel index modifications until desired.
(++) no need to synchronize/interfere between searchers and index updates.
(+++) stable non-corruptable index without duplicating index data.
Doron
[EMAIL PROTECTED] wrote on 05/03/2007 11:02:34:
That part is self understood. However as I describe the problem
initially - and the use case is a very practical way of dealing with
documents in real live - they change, we edit them, I don't want to
run a batch re-indexing thing every night... I just wanted done on
the spot. One instance IndexerSeacher it's the way to go I today
agree but because it's reader doesn't detect the changes in the
files because is not being used to do them it's pretty anoying don't
you all thing ?
-------------- Original message ----------------------
From: "Erick Erickson" <[EMAIL PROTECTED]>
<1>. Every time you close/open a reader, you pay a significant penalty
to warm up caches, etc. You may have to do some tricky dancing
to coordinate among the sessions to be able to close/reopen
the reader to allow updates to show up though.
Erick
On 3/5/07, Mohammad Norouzi <[EMAIL PROTECTED]> wrote:
Hi Erick
I am completely confused about this IndexReader.
in my case, I have to keep the reader opened because of pagination of
the
result so I have to had a reader per session. the thing that baffled
me is
can only one reader service all the session at the same time?
I mean
1- having one reader for all sessions and having a Hits for each
session.
2- one reader per session.
which one is right?
---------------------------------------------------------------------
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]
