Hi all. In our framework, we don't know what index you're going to access in advance. We're also not a server-side application, so we don't have any convenient "end of request" point at which we can close "everything you opened for that request".
However, we still want to share the underlying IndexReader instances when multiple of the same directory is loaded, and we do have a container of sorts (one per index) which knows when that particular session is done with that particular index. So it sounds like we should be using ReaderManager, but I'm having problems implementing anything reliable using it. In trying to associate each directory with its ReaderManager, I end up with a Map<String,Wrapper> (where Wrapper is just a stand-in for the name of the class I wrap around the ReaderManager.) If I let this map continue to grow indefinitely, everything shares out fine, but nobody ever closes the text index. Files don't get closed and tests fail. So it sounds like I want to track how many callers are using each ReaderManager and then when it gets to 0, close it. To this effect, I have found that I'm implementing my own reference counting for it, which I find a little odd because that seems to be ReaderManager's job. But OK, while thinking that was weird, I did try to implement this reference counting at our layer as well and am finding that the inability to override close() on FilterDirectoryReader was inconvenient - I wanted to get notified when the caller closed their copy of the reader, but I can only override onClose() which is only called when all callers have closed the reader, which never happens because the ReaderManager still has their copy open. So basically... How am I supposed to use this thing? (In many ways, it's too bad DirectoryReader.open doesn't share the readers for us. Derby, to contrast, does automatically share resources between two connections to the same database without us having to do anything at all.) TX --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
