> > > 1. Why don't we have as many control/manager object as index > > > we want to use? > > > 2. Why is it a static class with only static methods? > > > > That would destroy what this class is attempting to > > accomplish: Guarding > > the index resources so that you don't have to think about > > concurrency. If > > you could have multiple controllers, they would then have to somehow > > coordinate between themselves... making the class even more complex. > > > I mean we could have as many instance as many index (path or > directory) we want to manage. For example > IndexAccessControl iac = new IndexAccessControl(myPath); > Searcher searcher = iac.getSearcher();
Yes, but then you rely on the user to make sure that they don't create two on the same path, right? If you really don't like the static style for some reason (why?), I suppose we could have a static accessor like: "IndexAccessControl getController(path)" and maintain an internal map of controllers to avoid conflicts... > > > 3. Couldn't we wrap the release logic into a > > > ControledSearcher (Yesterday I've writter CachedSearcher)? > > > > Nope. For example, in my application I need to hold onto a > > single Searcher > > during the course of a transaction... if I was forced to use > > a new Searcher > > for each query, I couldn't be guaranteed consistent results > > throughout the > > transaction. > > You are not forced. You can hold reference to > ControledSearcher as long you want. I only suggest that > developer should call > searcher.close() > instead of > IndexAccessControl.releaseSearcher(searcher) Ah. Yes, good point. You're right, we should wrap all 3 (IndexReader, IndexWriter, and Searcher) classes for control purposes. (I guess I just hadn't thought about this because I already wrap and consolidate these 3 classes into 2 classes: A Searcher and a Writer where the writer handles add(), update(), and delete(). Maybe folks would be interested in that kind of thing as well...?) Scott
