Hello,
About http://www.jguru.com/faq/view.jsp?EID=913302 ...
--- Mark Harwood <[EMAIL PROTECTED]> 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.
./IndexReader.java: throw new IOException("Index locked for
write: " + writeLock);
./IndexWriter.java: throw new IOException("Index locked for write:
" + writeLock);
In IndexReader this is in a delete method, and in IndexWriter in the
constructor.
> 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... :)
Thanks,
Otis
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
