lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <>
Subject [jira] Commented: (LUCENE-2689) remove NativeFSLockFactory's attempt to acquire a test lock
Date Tue, 05 Oct 2010 16:35:32 GMT


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:
>             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

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:
For additional commands, e-mail:

View raw message