2010/10/5 Mindaugas Žakšauskas :
> The key bit: release(searcher) here calls IndexReader.decRef() which
> in turn closes the index when necessary.
Ahh yes.
> This approach has the same disadvantage of object pooling I have
> mentioned in my original email. The "do searching & rendering" phase
>
Hi,
Thanks for your input Mike.
As far as I understand, your suggestion is to do something like this:
IndexSearcher searcher = searcherManager.get();
try {
// do searching & rendering here…
} finally {
searcherManager.release(searcher) ;
}
The key bit: release(searcher) here calls IndexRead
Check out the SearcherManager class in Lucene in Action 2nd edition's
source code. It's free for download at Manning's site
(http://manning.com/lucene). NOTE: I am one of the co-authors.
I think that class does exactly what you're seeking. It uses
reference counts to ensure a reader is closed a
Hi,
I am keeping a ConcurrentMap of o.a.l.index.IndexReader which I use in
my system. These readers are retrieved by multiple threads and I have
no knowledge when these readers are actively used and when not.
When underlying index is updated, I reopen the reader and replace it in the map:
IndexR
