lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Armbrust, Daniel C." <Armbrust.Dan...@mayo.edu>
Subject RE: Lock handling and Lucene 1.9 / 2.0
Date Wed, 15 Sep 2004 20:32:08 GMT
I don't believe that Lucene is read locked for search.  It is only for initializing the IndexReader's.
 So, if each of your JVM's create and keep an IndexReader open, each of your JVM's should
be able to search on your single disk concurrently.  

Just don't create a new IndexReader every time you want to do a search.  Then the only time
you should have contention (on a read only index) would be if you started all 4 jvm's at the
exact same time....  Its different of course, if you are doing updates.


Dan

-----Original Message-----
From: Pete Lewis [mailto:pete@uptima.co.uk] 
Sent: Wednesday, September 15, 2004 3:22 PM
To: Lucene Developers List
Subject: Re: Lock handling and Lucene 1.9 / 2.0

Hi Otis

Our configuration is multi-JVM and single shared disk (4 * servers, 1 *
SAN).  Even having multiple dedicated IndexReaders would still cause us
iisues because of the shared disk access for the commit.lock file.....

Why are we being exclusive read locked for just a search?  I know we are not
using Lucene in the 'standard way' but feel that we've laid things out in
the best way for our environment, which is driven by issues other than just
search.

Yep, library == Lucene index.  Sorry, also working with different search
engine in the Terabyte range and they call their indexes 'libraries' and I
forget to make the switch sometimes.

Cheers

Pete Lewis

---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org


Mime
View raw message