Chris Hostetter wrote:
> : again. I don't think it matters if its the same FileChannel or not - you
> : just can't use Native Locks within the same JVM, as the lock is held by
> : the JVM - they are per process - so Lucene does its own little static
> : map stuff to lock within JVM (simple in memory lock tracking) and uses
> : the actual Native Lock for multiple JVMs (which is all its good for -
> : process granularity). But obviously, the in memory locking doesn't work
> : across webapps.
>
> Assuming I'm understanding all of this correctly, that implies a bug in
> Lucene's NativeFSLockFactory when used in a multiple classloader type
> situation -- including any app running in a servlet container.
>
> At a minimu, shouldn't NativeFSLock.obtain() be checking for
> OverlappingFileLockException and treating that as a failure to acquire the
> lock?
>
>
>
> -Hoss
>
>
Perhaps - that should make it work in more cases - but in my simple
testing its not 100% reliable.
If I startup two threads and and try and get a lock (with the same
channel, with different channels) with first one thread and then the
other - sometimes it throws OverlappingFileLockException
... and sometimes it doesn't. From what I can tell, you certainly can't
count on it.
If you pause between attempts, it does appear to always work - so it
certainly would give us a lot of ground it would seem - but if they
attempts are back to back, both threads can still successfully get the lock.
This behavior could be OS dependent as its using OS level locks.
FileChannel does appear to say that this should work (though its
obviously not completely thread safe from what I can tell), but it also
says:
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.
Which seems to be the case.
--
- Mark
http://www.lucidimagination.com
