Re: Pooling indexReader

2008-06-30 Thread Michael McCandless
I don't see why close must be final; I think we could/should relax that? But: I think your situation is perfect for incRef(). That method declares that someone is still using the IndexReader (until the corresponding decRef() is called). Mike John Wang wrote: Hi Mike: Thanks for the

Re: Pooling indexReader

2008-06-30 Thread John Wang
Hi Mike: Thanks for the reply! The reason my pattern wouldn't work is because my doClose impl does nothing to avoid the actual closing and then later my "index updater" will do the actual closing. The problem is although my doClose is called, the reference is decremented to 0, and ensureOp

Re: Pooling indexReader

2008-06-30 Thread Michael McCandless
It's true there is now reference counting logic to determine when it's really time to close an IndexReader, but, at that point doClose() is still called so your custom logic should still be running, right? It seems like your pattern ought to still be working? If not, another alternative

Pooling indexReader

2008-06-29 Thread John Wang
Hi: I had some code to do indexReader pooling to avoid open and close on a large index when doing lotsa searches. So I had a FilteredIndexReader proxy that overrides the doClose method to do nothing, and when I really want to close it, I call super.doClose(). This patter worked well for me prior