Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Searcher/Reader/Writer Management
Date: Wed, 3 Apr 2002 17:05:35 +0200
Message-ID: <50EA669584662B498F13A5F24630A0C0DB16DB@peach.mnet.private>
Thread-Topic: Searcher/Reader/Writer Management
Thread-Index: AcHbHaqQZ3nx3B3URme41H8u4clCvgAAmkNA
From: =?iso-8859-1?Q?Hal=E1csy_P=E9ter?= <halacsy.peter@axelero.com>
To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>


> -----Original Message-----
> From: Scott Ganyo [mailto:scott.ganyo@eTapestry.com]
> Sent: Wednesday, April 03, 2002 4:44 PM
> To: 'Lucene Developers List'
> Subject: RE: Searcher/Reader/Writer Management
>=20
>=20
> (quotes clipped for brevity)
>=20
> > 1. Why don't we have as many control/manager object as index=20
> > we want to use?
> > 2. Why is it a static class with only static methods?=20
>=20
> That would destroy what this class is attempting to=20
> accomplish:  Guarding
> the index resources so that you don't have to think about=20
> concurrency.  If
> you could have multiple controllers, they would then have to somehow
> coordinate between themselves... making the class even more complex.
>=20
I mean we could have as many instance as many index (path or directory) =
we want to manage. For example
IndexAccessControl iac =3D new IndexAccessControl(myPath);
Searcher searcher =3D iac.getSearcher();


> > 3. Couldn't we wrap the release logic into a=20
> > ControledSearcher (Yesterday I've writter CachedSearcher)?
>=20
> Nope.  For example, in my application I need to hold onto a=20
> single Searcher
> during the course of a transaction... if I was forced to use=20
> a new Searcher
> for each query, I couldn't be guaranteed consistent results=20
> 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)


>=20
> > 4. If I understand your code index can't be written while=20
> > there is opened searcher? Is it right? I don't understand=20
> > what is the connection between Reader and Writer instances on=20
> > the same index.
>=20
> You should be able to get a writer while searchers are in=20
> use, but not while
> a reader is in use.  Did you see a place where this is not=20
> the case?  I
> should have mentioned: In this scenario, Readers are assumed=20
> to be used for
> delete (since they can be), so a Writer cannot be retrieved=20
> while a Reader
> is open and vice versa.
>=20

Ok, I see.
>=20
> Scott
>=20

peter

--
To unsubscribe, e-mail:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>