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 Wed, 30 Aug 2006 11:20:25 GMT
    [ ] 
Michael McCandless commented on LUCENE-635:

With this change, "Directory on DB", "Directory on RAM", etc., still
work correctly.  In fact you can completely override the LockFactory
behavior by implementing your own "makeLock" in a subclass of
Directory if you want to.

This change just opens up the freedom to allow you to separately
choose how your locking is done.  I think this is important because
many applications have different locking requirements.  Perhaps you
require no locking at all (NoLockFactory or legacy
FSDirectory.setDisabledLocks), or everything happens in one JVM
(SingleInstanceLockFactory), etc.

This also opens up the chance for people to work around locking issues
eg over NFS until we can get lock-less commits finished.

I'm working on a LockFactory implementation that uses native OS locks
(java.nio.*) and this will be another place that accesses the file
system.  The (used by the
SimpleFSLockFactory) has a very spooky warning about not using it for

We could (as you're suggesting) indeed extend FSDirectory so that it
provided the low level methods required by a locking implementation,
and then alter SimpleFSLockFactory/NativeFSLockFactory (or make a new
LockFactory) so that all underlying IO is through the FSDirectory

> [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
>         Assigned To: Yonik Seeley
>            Priority: Minor
>             Fix For: 2.0.1
>         Attachments: LUCENE-635-Aug27.patch, 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