lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Boulton (JIRA)" <>
Subject [jira] [Commented] (LUCENE-5738) NativeLock is release if Lock is closed after obtain failed
Date Thu, 05 Jun 2014 23:44:01 GMT


Richard Boulton commented on LUCENE-5738:

I believe that Java's NativeFSLock uses fcntl on Linux.  Unfortunately, the semantics of fcntl
are consistent with the behaviour described above.


 - a process has first to open a file descriptor to obtain a lock with fcntl
 - when that file descriptor is closed, the lock is released
 - however, the lock is also released if any file descriptor on the same underlying file is
closed by the same process as is holding the lock.  (I'm not certain of the behaviour when
file handles are passed to other processes, either explicitly or by forking.)
 - the lock is not released, however, if a different process opens and then closes a file
descriptor on the file.

So, there are two approaches I know of to get the semantics you probably want (ie, that the
only way the lock is closed is if the process holding it exits, or the lock is explicitly

 1: make sure files which are locked aren't opened multiple times while locked.  This probably
needs some process-wide state to track which files have locks held on them.  This is, of course,
awkward for
a library, since you don't have control over code in the same process which isn't part of
the library.
 2: fork a subprocess to hold the lock open.  This is expensive, but is the approach we took
with Xapian.  I'm not sure it would be workable if you lock things at all frequently, though.

> NativeLock is release if Lock is closed after obtain failed
> -----------------------------------------------------------
>                 Key: LUCENE-5738
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Bug
>    Affects Versions: 4.8.1
>            Reporter: Simon Willnauer
>            Assignee: Simon Willnauer
>             Fix For: 4.9, 5.0
> if you obtain the NativeFSLock and try to obtain it again in the same JVM and close if
if it fails another process will be able to obtain it. This is pretty trappy though. If you
execute the main class twice the problem becomes pretty obvious.
> {noformat}
> import;
> import;
> import;
> import;
> public class TestLock {
>  public static void main(String[] foo) throws IOException, InterruptedException {
>         NativeFSLockFactory lockFactory = new NativeFSLockFactory(new File("/tmp"));
>         Lock lock = lockFactory.makeLock("LOCK");
>         if (lock.obtain()) {
>             System.out.println("OBTAINED");
>         } else {
>             lock.close();
>             System.out.println("FAILED");
>         }
>         // try it again and close it if it fails
>         lock = lockFactory.makeLock("LOCK"); // <<<<==== this is a new lock
>         if (lock.obtain()) {
>             System.out.println("OBTAINED AGAIN");
>         } else {
>             lock.close(); // <<<<==== this releases the lock we obtained
>             System.out.println("FAILED on Second");
>         }
>         Thread.sleep(Integer.MAX_VALUE);
>     }
> }
> {noformat}

This message was sent by Atlassian JIRA

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

View raw message