Hi Christoph We are in a cluster running under Bea Weblogic.
We have a static API to the search component from the portlets. We therefore need to open an indexreader per request. Cheers Pete ----- Original Message ----- From: "Christoph Goller" <[EMAIL PROTECTED]> To: "Lucene Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, September 14, 2004 10:55 AM Subject: Re: Lock handling and Lucene 1.9 / 2.0 > Pete Lewis wrote: > > Hi Christoph > > > > If we stand back a second and ask why we have commit locks when searching? > > > > The answer comes down to handling the FSDirectory - where the methods used > > are not j2ee compliant. > > > > We could open another can of worms and say why does the indexreader delete - > > but I won't go into that argument again here..... > > > > The bottom line is that we need the ability to search without waiting on a > > commit lock. > > You have this ability already !!!!!!!!!!!!!!!!!!!!!!!!! > > The FSDirectory is where the problems lie. We could hack the > > code to make it work for our particular application; however what I've been > > trying to get across is the need to have a method that will give users the > > capability to just search (not delete) without waiting upon the commit lock, > > that will be j2ee compliant, and that will be appropriate clustered > > implementations - and that this should be a candidate for Lucene 1.9 / 2.0. > > > > You say that it shouldn't take long to wait. A 1 sec spin lock per index > > per process is an eternity when trying to scale for potentially thousands of > > users. > > I have to admit that I am not an expert in j2ee compliancy. But I would like > to learn about it. If a database (I consder Lucene as a database) really has > to be initialized for every read-access, than there is a problem with j2ee > compliancy. I cannot believe that this is really true. > > LET ME STATE AGAIN: You should not open a new IndexReader for every > search/query. If you do so you definitely have a performance problem > independently from synchronization!!!!!!!!! Opening an IndexReader is > much more expensive than any individual query/search. > > You need a commit.lock for opening an IndexReader not because IndexReader > has delete functionality. You need it because if there is some process > writing to your index, your index may be in an inconsistent state. An existing > commit.lock indicates such an inconsistent state. Therefore, every writer needs > a commit.lock while committing, and every reader needs a commit.lock while > opening an index. > > Christoph > > > --------------------------------------------------------------------- > 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]
