You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (JIRA)" <ji...@apache.org> on 2015/05/28 12:27:17 UTC
[jira] [Comment Edited] (LUCENE-6507) Directory#makeLock is trappy
[ https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14562640#comment-14562640 ]
Uwe Schindler edited comment on LUCENE-6507 at 5/28/15 10:26 AM:
-----------------------------------------------------------------
Changing the behaviour of this already existing method would be an unexpected change, code outside Lucene would fall over that (like Infinispan directory,...). So we should break hard and invent a new name for the method, especially if we change behaviour. So code that wants to lock a directory fails to compile. I think we have 2 possibilities:
- newLockInstance() with the current behaviour
- lockDirectory() or aquireLock() or whatever to do the actual locking, returning the Lock instance
makeLock() should be removed so existing code fails to compile
I am sorry that I did not fix that before release of Lucene 5.0. This was on my list but I missed to fix the name or change behaviour.
This change here should also be reflected in the LockFactory class (not just in directory)...
was (Author: thetaphi):
Changing the behaviour of this already existing method would be an unexpected change, code outside Lucene would fall over that (like Infinispan directory,...). So we should break hard and invent a new name for the method, especially if we change behaviour. So code that wants to lock a directory fails to compile. I think we have 2 possibilities:
- newLockInstance() with the current behaviour
- lockDirectory() or aquireLock() or whatever to do the actual locking.
- makeLock() should be removed so existing code fails to compile
I am sorry that I did not fix that before release of Lucene 5.0. This was on my list but I missed to fix the name or change behaviour.
This change here should also be reflected in the LockFactory class (not just in directory)...
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org