[
https://issues.apache.org/jira/browse/LUCENE-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788616#action_12788616
]
Uwe Schindler commented on LUCENE-2104:
---------------------------------------
The problem with NativeFSLock is that you cannot release the lock if you are
not owning the lock. It is the same like with synchronized() blocks, you can
only unlock, if you own the lock.
If you use NativeFSLock you should never-ever try to forcefully unlock! If
there is a lock, then the dir is used and it would be the badest thing you
could do, to forcefully unlock. The O/S will take care of lock removal on JVM
exit.
I just repeat: IndexWriter.unlock() is only a last resort to forcefully remove
a lock file from SimpleFSLockFactory because the cleanup does not work. And I
want to repeat: Removing the lock file does not remove the lock. You test e.g.
fails on windows even with you patch, because Windows forcefully keeps the lock
and does not allow to remove the lock file until it is explicitely unlocked.
What you patch does on UNIX is, that it removes the lock file and therefore all
references in filesystem to the lock. If another index writer then tries to
lock again, it works, because the new file has another inode number and is a
different lock file. What you are tryng to do is completely broken.
> 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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
