[
https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14562760#comment-14562760
]
Uwe Schindler commented on LUCENE-6507:
---------------------------------------
Hi Robert,
I agree, but that is another problem. From reading Simon's issue description,
this issue is not about the bug you are talking about.
The problem described here is the following problem: if you call makeLock() on
a directory it just creates a lock instance, but does not actually lock. This
is a bit confusing regarding the naming of the method. makeLock() makes you
think that this method aquires the lock and returns an instance of the lock.
Simon then had the problem that because of the stupid naming, he unlocked the
unlocked (not yet locked) lock. This should be a no-op, so the bug may be there.
This is why my initial response was to rename the stupid named makeLock() to
newLockInstance(). makeLock sounds like "this already creates the lock".
> Directory#makeLock is trappy
> ----------------------------
>
> Key: LUCENE-6507
> URL: https://issues.apache.org/jira/browse/LUCENE-6507
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Simon Willnauer
>
> the lock API in Lucene is super trappy since the lock that we return form
> this API must first be obtained and if we can't obtain it the lock should not
> be closed since we might ie. close the underlying channel in the NativeLock
> case which releases all lock for this file on some operating systems. I think
> the makeLock method should try to obtain and only return a lock if we
> successfully obtained it. Not sure if it's possible everywhere but we should
> at least make the documentation clear here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
