lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Created: (LUCENE-635) [PATCH] Decouple locking implementation from Directory implementation
Date Thu, 27 Jul 2006 00:31:14 GMT
[PATCH] Decouple locking implementation from Directory implementation

                 Key: LUCENE-635
             Project: Lucene - Java
          Issue Type: Improvement
          Components: Index
    Affects Versions: 2.0.0
            Reporter: Michael McCandless
            Priority: Minor

This is a spinoff of

I've opened this new issue to capture that it's wider scope than

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

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