[
https://issues.apache.org/jira/browse/LUCENE-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019411#comment-14019411
]
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.
Specifically:
- 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 closed).
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: https://issues.apache.org/jira/browse/LUCENE-5738
> 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 org.apache.lucene.store.Lock;
> import org.apache.lucene.store.NativeFSLockFactory;
> import java.io.File;
> import java.io.IOException;
> 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
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
