lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Reuschling <>
Subject Refreshing IndexReaders for our desktop searching app
Date Tue, 27 May 2008 16:36:47 GMT
Hello out there,

We have implemented some open source desktop searching app based on Lucene

Development always goes further, and currently we make experiments with the
file-lock based writer (/reader) synchronization capabilities of Lucene, in
order to waste our current synchronization method, which is not such comfortable
to use.

I have a global writer Object and an according Reader, which is also global
accessible inside the application. For both there are getter methods, inside
the getReader() method we check with reader.isCurrent() whether there are
modifications inside the index or not. In the case there are modifications,
I close the reader and create a new one, returning it.

And this is exactly the problem. In the case there are still some references
to the old reader object, I get an IndexAlreadyClosedException.

I'm thinking for a while about this problem, and have also searched long time
inside the Lucene mailing list repository. The root of the problem is not to
close a reader Object if there is at least one reference to it left.

To ensure this, for my impression, we have the following possibilities:

1. Add a new method 'release reader' and count whether there are some unreleased
    reader Objects left. Only close if not. This makes coding much less comfortable,
    if you forget to release a reader after using it, it will end in excessive
    debugging sessions. Further, I personally think that this is not the 'spirit'
    of Lucene for this scenario...correct me if I'm wrong ;)

2. Add a finalizer to the reader object and perform a close() there. References to
    reader objects will stay valid. For this, I have to wrap the all Readers in order
    to add the finalize()...the wrap is also not so nice

3. Use the garbage collector for counting the references, and - maybe - use
    PhantomReferences to initialize a close process. I don't exactly know whether
    this is possible, because the Phantom reference gets null for its referent, so
    the invocation oof close() seems to be unpossible...

4. Simply don't close the reader Objects, and hope that this is no problem..

To change this hope into knowledge: Is it critical NOT closing an IndexReader Object
in the case it is used only and entirely read-only? We use the new IndexWriter
to delete documents in all cases.

If it is critical - is there a common  - or uncommon but good - solution for this, that
I have forgotten?


View raw message