[
https://issues.apache.org/jira/browse/LUCENE-6508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567137#comment-14567137
]
Michael McCandless commented on LUCENE-6508:
--------------------------------------------
bq. I thought about this too, but for a number of reasons I dislike it:
But locking is already an internal API, so we are free to do this
simplification on 5.x?
We are a search engine not a generic locking platform.
It doesn't make sense that our locking impl be generic beyond what we need
internally ("only one thing can write to a directory at a time").
Or, maybe:
bq. leave the possibility of other locks for other purposes if we need them.
...you could shed light on what future locking needs Lucene might have? I feel
like we should design for today, especially on a part of Lucene that has had so
much trouble/bugs.
Maybe as a compromise we could fix the API to refuse to make any lock that's
not named IndexWriter.WRITE_LOCK_NAME.
Anyway, I'm OK with leaving the API "generic" (pass any lock name you want)
here... this branch already has enough great improvements. We should wrap it
up and commit...
> Simplify Directory/lock api
> ---------------------------
>
> Key: LUCENE-6508
> URL: https://issues.apache.org/jira/browse/LUCENE-6508
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Assignee: Uwe Schindler
> Attachments: LUCENE-6508-deadcode1.patch, LUCENE-6508.patch,
> LUCENE-6508.patch
>
>
> See LUCENE-6507 for some background. In general it would be great if you can
> just acquire an immutable lock (or you get a failure) and then you close that
> to release it.
> Today the API might be too much for what is needed by IW.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
