[
https://issues.apache.org/jira/browse/LUCENE-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788697#action_12788697
]
Shai Erera commented on LUCENE-2104:
------------------------------------
Thanks for the info Uwe. I know the unlock is to be used as a last resort, and
if you know no one else has a reference to the lock. The fact that on Windows
this fails is perfect, that's exactly what I want - for unlock() to fail if
someone keeps a reference to the lock. On Unix - I didn't realize that's what
happens, so that's indeed broken.
I'm not sure that the fix is just javadocs ... perhaps the fix should be to add
an unlock() method to Lock and impl it in SimpleFSLock by calling release(),
but on NativeFSLock to first obtain the lock and if that succeeds, release it.
That way, the obtain would fail and we can throw an exception. Also, we can
keep release() and impl in NativeFSLock to first obtain if it does not hold the
lock.
Also, what you say about IndexWriter.unlock() should be used if
SimpleFSLockFactory is used, and only then, is not: (1) documented anywhere and
(2) reasonable. What if I implement a Lock over a DB (I think someone even
posted something about that a while ago). I should still be able to call
unlock().
The thing is, IMO unlock() should throw an exception if it failed, and
currently it does so in SimpleFSLock but not for NativeFSLock. The symmetry is
broken, and I see no reason why it shouldn't fail for NativeFSLock, so the
application knows about it. Notice that NativeFSLock fails to thrown an
exception only because makeLock creates a new instance with the 'lock' member
being null. It gives a false impression that the unlock succeeded, and for the
wrong reason.
> 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]
