Pete, You can use the same IndexReader by multiple threads. It sounds like you are not aware of this (I think this is a FAQ actually... on jGuru). So, single IndexReader used by multiple threads == OK && does not require commit.lock on ever 'read'. Just one commit.lock when IndexReader is opened, or when you use IndexReader to delete a Document.
When you say 'library', you are really referring to a Lucene index, correct? Otis --- Pete Lewis <[EMAIL PROTECTED]> wrote: > 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" <[EMAIL PROTECTED]> > To: "Lucene Developers List" <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
