> 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 * http://www.blizzy.de GPG public key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1F11D713 Key fingerprint: CF19 AFCE 6E3D 5443 9599 18B5 5640 1F11 D713 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
