lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Ganyo <>
Subject Re: No timeout for "write.lock"
Date Thu, 08 May 2003 14:14:49 GMT
Yes, I understand why the lock is there, I'm just wondering if anyone 
but me would like to see a timeout on it and if there is anything 
prohibiting it.  From your answer, it doesn't sound like there is any 
technical reason to not have a timeout on the lock.  Further, I think it 
could be very useful for multi-threaded, multi-user applications like mine.

For example, the database I use has a timeout mechanism to obtain a 
write lock on an object.  In practice this is very useful, for if I need 
to get a write lock on an object to do my work, I'm generally willing to 
wait a little bit rather than immediately get an error and give up.  And 
while you could have a thread/process that holds the write lock for a 
lengthy period of time, if you are aware of the dangers of this you 
write your application to ensure that write locks are held for as small 
a period of time as possible to ensure that, in general, you get the 
lock after a minimal wait.

So, I suggest we add the ability to wait on a write lock and make it a 
configurable timeout.  That way if you have a application that needs to 
get work done and is willing to wait a little bit, you can tell it to do 
that.  Conversly, if for some reason you'd rather simply give up 
immediately when there is a write lock, you would be able to do that as 


For those that would not be interested in

Doug Cutting wrote:

> Scott Ganyo wrote:
>> Is there a reason/what is the reason why the write.lock isn't using 
>> the wait/timeout mechanism?
> Yes.  Lucene only permits a single process to modify an index at once. 
> Multiple processes are permitted to read an index at once, but only 
> one can modify it.  The write.lock enforces this, and applications 
> should be written accordingly.
> Also, a process can own the write lock for an arbitrarily long time 
> (as long as an IndexWriter is open) so a timeout doesn't really make 
> sense.  The commit.lock is never held for more than the time it takes 
> to open all of the files in the index, or to write the segments file.  
> This should never take more than a second, and in most cases should be 
> much faster than that.  So it makes sense to have a timeout on that lock.
> Doug
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

"They who can give up essential liberty to obtain a little temporary safety deserve neither
liberty nor safety." - Benjamin Franklin

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message