lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <>
Subject Re: DO NOT REPLY [Bug 34995] - Contribution: LuceneIndexAccessor
Date Sun, 22 May 2005 18:17:06 GMT
Hi Maik,

So what happens in this case:

IndexAccessProvider accessProvider = new IndexAccessProvider(directory,
LuceneIndexAccessor accessor = new LuceneIndexAccessor(accessProvider);;
IndexWriter writer = accessor.getWriter();
// reference to the same instance?
IndexWriter writer2 = accessor.getWriter();

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

It looks like you answered that in Bugzilla already.  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.

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

To deal with managing index-modifying access to the index I often use
code that acts as a facade to IndexReader/Writer and provides methods
such as index(....), optimize(), and delete(....).  All of these
methods have index-modifying code inside a "synchronized
(_myDirInstanceHere)" block.  And that seems to work without the need
to open, close, and release explicitly.
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. :)


--- Maik Schreiber <> wrote:
> > I didn't follow this closely, but are you saying that
> > LuceneIndexAccessor then replaces IOError caused by locking with
> > blocking calls?  It sounds like the client of LuceneIndexAccessor
> still
> > needs to keep track of open IndexReaders, IndexWriters, etc., or
> else
> > one can end up with a hard-to-track blocked call somewhere in the
> code,
> > no?  It would be nice to see how this works via a unit test.
> Please see
> The client just does getWriter(), getReader() or whatever it wishes,
> then
> uses release() to give the instances back. The index accessor is
> responsible
> for synchronizing access such that no two writers can be open at the
> same
> time etc.

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

View raw message