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]
