Lucene does provide locking so that two JVM's can access the same index.
Check out the LockFactory to control how this is done.
There are a couple advantages of using IndexAccessor:
For one you could use a NoLockFactory and avoid Lucene's locking
mechanism. Also, you would only need to run one JVM.
Indexaccessor also causes new Readers to be opened as soon as a Writer
is done...this allows for a fairly interactive index rather than having
to reopen readers periodically...rather new content was added or not.
Also, access to Writing Readers, Writers, and Reading Readers, is all
handled behind the scenes for you...you dont have to worry about what
threads are doing what based on Lucene's index access rules...just
request the Writer/Reader you need, use it, release it, and your good.
Probably there is more...
- Mark
Dino Korah wrote:
Hi All,
I have a scenario where there are two processes (2 JVMs) accessing the same
index. One of them is doing the indexing as documents arrive into the system
and the second one servers search queries. Both the processes are running on
the same machine.
Is there a need to do some kind of locking. Does the writer process need to
know about the reader, for optimal performance of the query server? Using a
RAMDirectory<http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/javadoc/org/apache/lucene/store/RAMDirectory.html>for
adding documents and then merging it into the main index periodically;
would that help in improving the query performance in any way, provided the
Searcher is kept open for a long period of time, with reload at intervals.
I remember reading a thread of discussion on IndexAccessor. I would like to
know what would be the advantage in using IndexAccessor.
Many thanks.
Dino
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
