[
https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14563897#comment-14563897
]
Uwe Schindler commented on LUCENE-6507:
---------------------------------------
With LUCENE-6508, double obtains will be impossible in the future: you just get
a Lock instance if you have actually locked the directory (using
Directory#obtainLock(name)). This lock class is immutable and once released
with close() its gone. Because the new Lock class has no "obtain" anymore,
double obtains are impossible.
But as this new issue takes longer, we just did a "quick" fix to make 5.2
release-able.
> NativeFSLock.close() can invalidate other locks
> -----------------------------------------------
>
> Key: LUCENE-6507
> URL: https://issues.apache.org/jira/browse/LUCENE-6507
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Simon Willnauer
> Priority: Blocker
> Fix For: 4.10.5, 5.2
>
> Attachments: LUCENE-6507.patch, LUCENE-6507.patch, LUCENE-6507.patch,
> LUCENE-6507.patch, LUCENE-6507.patch, LUCENE-6507.patch, LUCENE-6507.patch,
> LUCENE-6507.patch, LUCENE-6507.patch, LUCENE-6507.patch, LUCENE-6507.patch
>
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
