[
https://issues.apache.org/jira/browse/LUCENE-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788599#action_12788599
]
Uwe Schindler edited comment on LUCENE-2104 at 12/10/09 8:54 AM:
-----------------------------------------------------------------
In general, there is no problem with NativeFSLock at all, because the removal
of the lock file is just a "cleanup", which is not needed (not deleting the
lock file would produce no problem - we only delete it to be interoperable with
SimpleFSLockFactory). The existence of a lock file is no indice for a locked
directory, only if a lock is "on the file". The JVM normally automatically
removes lock files on exit.
Removing the lock file to "unlock" is also a no-op, because even if the lock
file is removed, the lock still exists (unix delete on last close semantics).
The unlock method in IndexWriter is just for SimpleFSLockFactory and is of no
use for any other lock factory.
was (Author: thetaphi):
In general, there is no problem with NativeFSLock at all, because the
removal of the lock file is just a "cleanup", which is not needed (not deleting
the lock file would produce no problem - we only delete it to be interoperatble
with SimpleFSLockFactory). The existence of a lock file is no indice for a
locked directory, only if a lock in "on the file". The JVM normally
automatically removes lock files on exit.
Removing the lock file to "unlock" is also a no-op, because even if the lock
file is removed, the lock still exists (unix delete on last close semantics).
The unlock method in IndexWriter is just for NativeFSLockFactory and is of no
use for any other lock factory.
> IndexWriter.unlock does does nothing if NativeFSLockFactory is used
> -------------------------------------------------------------------
>
> Key: LUCENE-2104
> URL: https://issues.apache.org/jira/browse/LUCENE-2104
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Shai Erera
> Fix For: 3.1
>
> Attachments: LUCENE-2104.patch
>
>
> If NativeFSLockFactory is used, IndexWriter.unlock will return, silently
> doing nothing. The reason is that NativeFSLockFactory's makeLock always
> creates a new NativeFSLock. NativeFSLock's release first checks if its lock
> is not null. However, only if obtain() is called, that lock is not null. So
> release actually does nothing, and so IndexWriter.unlock does not delete the
> lock, or fail w/ exception.
> This is only a problem in NativeFSLock, and not in other Lock
> implementations, at least as I was able to see.
> Need to think first how to reproduce in a test, and then fix it. I'll work on
> it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
