lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maik Schreiber <>
Subject Re: DO NOT REPLY [Bug 34995] - Contribution: LuceneIndexAccessor
Date Sun, 22 May 2005 19:01:38 GMT
> IndexWriter writer = accessor.getWriter();
> // reference to the same instance?
> IndexWriter writer2 = accessor.getWriter();
> writer.addDocument(....);
> writer2.addDocument(....);

Yes, regardless of which thread invokes getWriter(). This means multiple
threads are concurrently able to add new documents.

> // I didn't release the writer yet
> // will this block?
> IndexReader reader = accessor.getReader();
> reader.delete(....);

If you've invoked getReader(true), then it will block. With getReader(false)
it won't block, but the Reader should be used for write access in that case.

> But doesn't that
> make management of IndexWriter/IndexReader as "involved" as doing it
> directly?  Is the idea that this shields the user from needing to do
> his own synchronization?  Actually, I can see how working with this
> code can be simpler than dealing with details yourself.

You've just answered that yourself. LuceneIndexAccessor removes your burden
to synchronize index access between multiple threads. Granted, in a
single-threaded environment there might not be much use for it.

> Is there a way to time out the blocking getWriter/Reader()?

Not yet, but the code can be easily modified.

> I guess such code doesn't give you direct access to IndexReader/Writer,
> so that's the drawback.... and I guess the synchronization really
> blocking as well. :)

Yes, I think your approach is more prone to contention. LuceneIndexAccessor
tries to avoid contention where possible.

Maik Schreiber   *

GPG public key:
Key fingerprint: CF19 AFCE 6E3D 5443 9599 18B5 5640 1F11 D713

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

View raw message