You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by petite_abeille <pe...@mac.com> on 2003/10/29 18:03:21 UTC
java.nio.channels.FileLock
Hello,
Just stumbled upon that:
http://java.sun.com/j2se/1.4.1/docs/api/java/nio/channels/FileLock.html
Which might be of interest to Lucene if the library ever migrates to
1.4 :)
Cheers,
PA.
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: java.nio.channels.FileLock
Posted by petite_abeille <pe...@mac.com>.
On Oct 29, 2003, at 19:08, Ronald Muller wrote:
> What is the advantage of using a FileLock object instead of the way
> Lucene
> does it? (I do not see it)
Less code. Less worries.
> 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."
Perhaps. Have you used it? Any practical experience with it? For or
against?
Cheers,
PA.
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: java.nio.channels.FileLock
Posted by Francesco Bellomi <fb...@libero.it>.
Hi,
Ronald Muller <rk...@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
Re: java.nio.channels.FileLock
Posted by Ronald Muller <rk...@12move.nl>.
What is the advantage of using a FileLock object instead of the way Lucene
does it? (I do not see it)
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."
Ronald Muller
----- Original Message -----
From: "petite_abeille" <pe...@mac.com>
To: <lu...@jakarta.apache.org>
Sent: Wednesday, October 29, 2003 6:03 PM
Subject: java.nio.channels.FileLock
> Hello,
>
> Just stumbled upon that:
>
> http://java.sun.com/j2se/1.4.1/docs/api/java/nio/channels/FileLock.html
>
> Which might be of interest to Lucene if the library ever migrates to
> 1.4 :)
>
> Cheers,
>
> PA.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org