Safe tracking of multiple ReaderManager for multiple directories

[Trejkaz <tr...@trypticon.org>]

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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org