lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Harwood <>
Subject Re: Thread safety
Date Fri, 14 Jun 2002 16:41:43 GMT
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)

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.

One approach discussed previously is to simply have a read-only index serving 
multiple concurrent search requests and use a separate write-capable index to 
apply updates in a single-threaded mode - the updated index is then 
"hot-swapped" onto the search server. This avoids the issues related to 
read-update contention.

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?).

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.


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

View raw message