[ https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14562640#comment-14562640 ]
Uwe Schindler commented on LUCENE-6507: --------------------------------------- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org