lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Commented: (LUCENE-635) [PATCH] Decouple locking implementation from Directory implementation
Date Thu, 17 Aug 2006 22:56:16 GMT
    [ ] 
Michael McCandless commented on LUCENE-635:

Thank you!  I agree, locking is sneaky and requires very thorough
review & testing.

Nice, I definitely like that more compact version of
SingleInstanceLockFactory.obtain -- I'll fold that in.

On FSDirectory.disableLocks, which is a private static boolean set by
"setDisabledLocks", if this is "true" when the FSDirectory is created
then FSDirectory uses the NoLockFactory for its locking; else it uses
the default SimpleFSLockFactory.  (This is only when the caller did
not provide a LockFactory instance).

OOH I do see one difference: in the current code, if you call
setDisableLocks then this affects even a previously created
FSDirectory, with the current code.  But with my changes, only newly
created FSDirectory instances will have locking disabled.  Ie, it's no
longer "retroactive" to all previously created FSDirectory instances,
with my change.  Hmm.  OK I will fix this case.

On SimpleFSLock.obtain, you are correct: I lost the creation of the
lock dir (if it doesn't exist) with each obtain.  Good catch!  I
didn't mean to lose it.  I will put it back in, and move it out of the
init() method in SimpleFSLockFactory.

Thanks for reviewing this!

> [PATCH] Decouple locking implementation from Directory implementation
> ---------------------------------------------------------------------
>                 Key: LUCENE-635
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Index
>    Affects Versions: 2.0.0
>            Reporter: Michael McCandless
>            Priority: Minor
>         Attachments: LUCENE-635-Aug3.patch, patch-Jul26.tar
> This is a spinoff of
> I've opened this new issue to capture that it's wider scope than
> LUCENE-305.
> This is a patch originally created by Jeff Patterson (see above link)
> and then modified as described here:
> with some small additional changes:
>   * For each FSDirectory.getDirectory(), I made a corresponding
>     version that also accepts a LockFactory instance.  So, you can
>     construct an FSDirectory with your own LockFactory.
>   * Cascaded defaulting for FSDirectory's LockFactory implementation:
>     if you pass in a LockFactory instance, it's used; else if
>     setDisableLocks was called, we use NoLockFactory; else, if the
>     system property ""
>     is defined, we use that; finally, we'll use the original locking
>     implementation (SimpleFSLockFactory).
> The gist is that all locking code has been moved out of *Directory and
> into subclasses of a new abstract LockFactory class.  You can now set
> the LockFactory of a Directory to change how it does locking.  For
> example, you can create an FSDirectory but set its locking to
> SingleInstanceLockFactory (if you know all writing/reading will take
> place a single JVM).
> The changes pass all unit tests (on Ubuntu Linux Sun Java 1.5 and
> Windows XP Sun Java 1.4), and I added another TestCase to test the
> LockFactory code.
> Note that LockFactory defaults are not changed: FSDirectory defaults
> to SimpleFSLockFactory and RAMDirectory defaults to
> SingleInstanceLockFactory.
> Next step (separate issue) is to create a LockFactory that uses the OS
> native locks (through java.nio).

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message