Hi, Ronald Muller <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
