[
https://issues.apache.org/jira/browse/LUCENE-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918061#action_12918061
]
Shai Erera commented on LUCENE-2689:
------------------------------------
Oh sure, we should return an Object upon makeLock. I was just asking whether
makeLock should return an already obtained lock. Instead of just "return new
Lock()", we do "Lock l = new Lock(); l.obtain();". That way, if obtain fails,
makeLock fails as well. That's sort of what acquireTestLock attempted to
achieve, no?
At any rate, today you can call makeLock, succeed in obtaining the test lock,
but later fail on obtaining the real lock. Hence, if we attempt to obtain on
makeLock (removing obtain from the API?), we guarantee to the user that this
lock is valid and should later be released.
I don't mind if we stay w/ the current API as well.
> remove NativeFSLockFactory's attempt to acquire a test lock
> -----------------------------------------------------------
>
> Key: LUCENE-2689
> URL: https://issues.apache.org/jira/browse/LUCENE-2689
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 3.0.1
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 3.1, 4.0
>
>
> NativeFSLockFactory tries to acquire a test lock the first time a lock is
> created. It's the only LF to do this, and, it's caused us hassle
> (LUCENE-2421, LUCENE-2688).
> I think we should just remove it. The caller of .makeLock will presumably
> immediately thereafter acquire the lock and at the point hit any exception
> that acquireTestLock would've hit.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
