Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <12bc01c49b0a$81a32ef0$34c2e550@joseph>
From: "Pete Lewis" <pete@uptima.co.uk>
To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
References: <20040914111147.550.qmail@web12701.mail.yahoo.com>
 <114101c49a93$1d987fe0$34c2e550@joseph> <41475ED1.6010001@apache.org>
Subject: Re: Lock handling and Lucene 1.9 / 2.0
Date: Wed, 15 Sep 2004 10:58:06 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Doug

Weblogic creates a pool of objects for us which are re-initialised each time
the constructor is called.  Its when we grab an IndexReader out of the pool
that we have the creation of the cache, which is where the spin originates.

Been thinking about your suggestion of a Hashtable (based on library name)
for the storage of IndexReaders, but then we'd get a bottleneck of access -
having a single reader per library means only a single process can access
the library (for reading) at once, and this would create a potential
bottleneck across our servers.  Another way might be to create a pool of
IndexReaders and allocate them on demand, ie 10 IndexReaders per library.
This would allow for 10 synchronous searches with no commit lock spin, but
would be a pain to code.

Probably would be quickest to create a system property that will enable us
to turn on/off the commit lock around the FSDirectory cache creation, so
we'd have them off when we get an IndexReader for just a read but have the
locks on at other times - don't want to disable all locks as our libraries
are dynamic and not static.

Sorry the constructive criticism was off-the-wall but it had made my head
hurt getting to the bottom of where our waits on spin locks had come from
;-)

Cheers

Pete Lewis

----- Original Message ----- 
From: "Doug Cutting" <cutting@apache.org>
To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
Sent: Tuesday, September 14, 2004 10:12 PM
Subject: Re: Lock handling and Lucene 1.9 / 2.0


> Pete Lewis wrote:
> > The only way to continually use the same IndexReader would be to use a
> > stateful session bean (frowned upon by J2EE Container writers)
>
> Can one implement DB connection pooling in J2EE?  This is analogous.
> One may keep a pool of IndexReaders that are reused by subsequent
> queries.  One difference is that the cache need only contain a single
> IndexReader per index, rather than a DB connection pool, which typically
> keeps multiple connections per DB.  Also, at checkout, the cache code
> should check whether a newer version of the index is available, and, if
> it is, update the cache.
>
> If there are lots of different indexes, more than you'd like to keep
> open at once, then an LRU cache might work well, implemented e.g. with
> LinkedHashMap.  Such a cache might be a useful contribution to Lucene.
>
> > I thought that it might be a good candidate for Lucene 2 as the
FSDirectory
> > code is horrible and non-J2EE compliant.
>
> Your constructive criticism is greatly appreciated!
>
> Have a nice day,
>
> Doug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>


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