lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francesco Bellomi" <fbell...@libero.it>
Subject Re: java.nio.channels.FileLock
Date Wed, 29 Oct 2003 20:17:58 GMT
Hi,

Ronald Muller <rk.muller@12move.nl> wrote:
> What is the advantage of using a FileLock object instead of the way
> Lucene does it? (I do not see it)

FileLock makes use of the underlying locking mechanism of the OS that is
more robust, whereas I think current Lucene implementation has some problems
if the JVM dies unexpectedly, because some locks may be left behind, and
subsequent Lucene processes may find the index locked even if the process
that originally created the lock no more exists.

Also, I believe (but I'm not sure) that FileLock could be more efficient,
because it does not require the creation of a file in the file system.

>
> Also note an mportant limitation:
> "File locks are held on behalf of the entire Java virtual machine.
> They are not suitable for controlling access to a file by multiple
> threads within the same virtual machine."

I think a reliable locking mechanism should combine local synchronization
mechanisms for thread-safety in the same VM, with file locking for
concurrency safety between multiple VM.

Also, I noticed that 1.3 RC2 puts locks in "java.io.tmpdir", which
initialized as the default system directory for temporary files. I think
this default can cause some troubles, if two processes running in different
machines are using the same index in a shared file system, because the two
machines have different (local) default temp dir.

Francesco


-
Francesco Bellomi
"Use truth to show illusion,
and illusion to show truth."



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


Mime
View raw message