[
https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14562809#comment-14562809
]
Robert Muir commented on LUCENE-6507:
-------------------------------------
Well, I think we should try to simplify the API, as always. But to me that is
polishing the silverware when the house is burning down. We need to fix the
bugs first.
As far as simplifying the API, it would be great if it was just one single
method that returned an obtained-lock, and then these locks wouldn't need any
mutable state. I'm not sure if all the crazy methods we have are really needed,
we should see what is the minimal thing we can get away with.
> Directory#makeLock is trappy (it does not aquire lock, although its name
> implies) + NativeFSLock.close() has side effects
> -------------------------------------------------------------------------------------------------------------------------
>
> 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]
