lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Ganyo <scott.ga...@eTapestry.com>
Subject RE: Searcher/Reader/Writer Management
Date Wed, 03 Apr 2002 15:24:10 GMT
> > > 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message