lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Halácsy Péter <halacsy.pe...@axelero.com>
Subject RE: Searcher/Reader/Writer Management
Date Tue, 09 Apr 2002 12:33:25 GMT
Hello Scott,
I've attached a new version of IndexAccessControl and a TEST file. First of all I think I've
found a failure in you code:
1. get a searcher
2. use it
3. release it
4. get an other searcher
5. use it

In step 3. -- since there is only one reference to the searhcer -- the real searcher is closed:
<original-code>
     else // last reference to searcher
                {
                    info.searcher.close();
                }
</original-code>
The info isn't deleted.

In step 4. in method getSearcher the info is found and the closed Searcher object is returned.

Other:
a. I changed the IndexAccessControl it's not static any more. You can make a new instance
for every index.
b. I created a ManagedSearcher class that is returned by getSearcher. If you call close method
of this class it notifies the IndexAccessControl to release the searcher.
So the usage:
IndexAccessControl iac = IndexAccessControl.getInstance("/pathToIndex");
Searcher searcher = iac.getSearcher();
// use the searcher
searcher.close();

If you like this architecture we could improve the code:
1. decoupling factory method and access control logic
2. decoupling searcher managment and reader/writer managment
3. solve the problem of last used searcher: if the last used searcher is released the searcher
is closed. Getting searcher again takes a lot of time. We should have a pool of searcher where
the size of pool is 1. 

Unfortunatla to use compile and use ManagedSearcher class you have to modify lucene source:
the Searcher has not public abstract methods --> you can't maka subclass of Searcher in
other package that org.apache.lucene.search.

To use the class modify all abstract method of org.apache.lucene.search.Searcher to public
or protected.

peter


> -----Original Message-----
> From: Scott Ganyo [mailto:scott.ganyo@eTapestry.com]
> Sent: Wednesday, April 03, 2002 5:24 PM
> To: 'Lucene Developers List'
> Subject: RE: Searcher/Reader/Writer Management
> 
> 
> > > > 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
View raw message