lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trejkaz <trej...@trypticon.org>
Subject Can I still use SearcherManager in this situation?
Date Wed, 07 Nov 2012 04:08:52 GMT
In our application, most users sit around in read-only mode all the time
but there is one place where write access can occur, which is essentially
scripted at the moment. (*)

Currently, we start out opening an IndexReader. When the caller declares
that they are going to start writing, we open an IndexWriter. When they
finish writing, they declare that, at which point we close the IndexWriter
and reopen the IndexReader.

NRTManager vaguely sounded like the thing for the job but since we don't
have an IndexWriter from the start, I guess it cannot be used (actually, at
the start, you don't even know if you have write access - and even if you
do, you shouldn't be locking the index unless you're really going to make
changes. Otherwise you will be depriving some other user of doing the
same...)

Currently I'm looking at SearcherManager. It looks like the current API has
maybeRefresh(), which spins off a refresh in the background, but unlike
NRTManager, doesn't appear to have any way to wait for that refresh to
finish. Essentially I want to know when I can get a new IndexSearcher which
is up to date with my written changes.

Is there some "right" way to do this? I hope I don't have to reimplement
some weird combination of SearcherManager and NRTManager myself.

TX


(*) The larger case of writing bulk data to the index is done while the
index is not openable by the user, so it is excluded from the problem space
for now. Later it would be nice to do something about that as well, but
there are various problems.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message