lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Ganyo <scott.ga...@eTapestry.com>
Subject RE: Using Lucene in a production environment
Date Wed, 03 Oct 2001 22:13:42 GMT
Thanks, Doug.  That's exactly what I was looking for.

Scott

> -----Original Message-----
> From: Doug Cutting [mailto:DCutting@grandcentral.com]
> Sent: Tuesday, October 02, 2001 4:49 PM
> To: 'lucene-user@jakarta.apache.org'
> Subject: RE: Using Lucene in a production environment
> 
> 
> > From: Scott Ganyo [mailto:scott.ganyo@eTapestry.com]
> > 
> > I have a couple of questions on using Lucene in a production 
> > environment:
> > 
> > 1) Are updates to an index "transactional" in nature?  In 
> > other words, can
> > an index ever get into an inconsistent/corrupt state by 
> > killing a writing
> > process?
> 
> No, it should not be possible to put an index in an 
> inconsistent or corrupt
> state.  The only problem might be that, after a crash, lock 
> files may need
> to be manually removed.
> 
> > 2) Can you describe where the synchronization points/locks 
> > are applied and
> > released?  I would like to make sure I avoid any situations 
> > that might cause
> > performance degradation or deadlock in my application.
> 
> The primary synchronization point is during calls to 
> IndexReader.open() and
> IndexWriter.close().  Only one thread may be in this at a 
> time.  For that
> reason, and for others, one should re-use IndexReader 
> instances.  Since
> IndexReader is thread-safe, this is not hard.  One 
> IndexReader per index is
> all that you should need at a time.  When the index changes, 
> you should
> create a new IndexReader.  The IndexReader.lastModified() 
> method is designed
> to make this easy.  The typical use should be to cache a 
> single index reader
> per index, check to see if it is out of date each time the cache is
> accessed, and replace it when it is.
> 
> IndexWriter.close() commits changes.  Aborting without 
> closing will leave
> the index locked but otherwise consistent.
> 
> Doug
> 

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