lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <>
Subject Re: Thread safety
Date Fri, 21 Jun 2002 14:05:54 GMT

About ...

--- Mark Harwood <> wrote:
> I think in many respects the table may be an over-simplification of 
> lower-level detail eg it does not show if each of the concurrent
> threads are 
> actually using the same IndexReader objects, IndexWriter objects or
> are even 
> operating in the same process (I think I read that write.lock file
> enables an Index to be opened by more than one process)

No, I think write.lock is there to tell other processes/threads to back
off, becase some process/thread is already modifying the index.  This
instruction is delivered as an exception.

./        throw new IOException("Index locked for
write: " + writeLock);

./      throw new IOException("Index locked for write:
" + writeLock);

In IndexReader this is in a delete method, and in IndexWriter in the

> I suspect many Lucene users are like myself and are keen to
> understand what 
> the concerns are when trying to set up a server and provide it with
> an ongoing 
> stream of new documents or changes. This table is trying to offer
> that high-level overview.

> If you are going to attempt to have just one index serving search
> requests and 
> processing changes/additions then you need to manage some of the
> contention eg 
> doc changes require a delete and a write and this requires careful 
> synchronization because of the restrictions on IndexReader.delete
> while a  IndexWriter is open.
> This level of detail may be too much to encapsulate in a simple table
> (BTW, how does your triangle alternative work?).

Yes, I'm curious about this, too.

> You are right in that the table as it stands doesn't show thread
> safety. I 
> think it shows Lucene's management of contention. The "N"s are
> actually areas 
> of contention where Lucene doesn't synchronize access (ie blocking
> one thread 
> until another finishes) and instead simply throws an exception. The
> user is 
> forced to ensure this condition never occurs and must sequence these
> requests 
> appropriately. All the "Y" points in the table show areas where
> Lucene is 
> happy to process simultaneous requests and (hopefully!) is
> synchronizing 
> access to resources that would otherwise corrupt the index.

If that is so, should there not be 'N' at delete/delete intersection?
Lucene doesn't manage the scenario where 2 processes/threads try to
delete a document from an index at the same time.  That's that
exception quoted above.
The same goes for write/write intersection.  That should then be an 'N'
as well, no?  That corresponds to the second exception quoted above.

I'd hate to have a misleading and incorrect FAQ entry there.  Poor
people... :)


Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message