lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-635) [PATCH] Decouple locking implementation from Directory implementation
Date Fri, 18 Aug 2006 21:48:16 GMT
    [ http://issues.apache.org/jira/browse/LUCENE-635?page=comments#action_12429135 ] 
            
Michael McCandless commented on LUCENE-635:
-------------------------------------------


OK, does anyone have a strong opinion one way or another on these
small changes?

I would lean towards keeping the small change to "setDisabledLocks()".
Meaning, it's only when you create a FSDirectory that the static
"disableLocks" value is checked.  So, changing disabledLocks would no
longer retroactively affect all previously created FSDirectories,
which seems too "powerful" -- what if I wanted some to be disabled and
others not?  Was it intentional that it was this powerful?  If we do
this we could document it in CHANGES.txt as a small difference.  Or,
again, I can put back the old behaviour if people think that's best.

On the second one, I agree we should keep the current behaviour of
checking existence of & creating the LOCK DIR with each obtain.  There
would be some performance benefit to only doing it on creating the
lock factory, but, I don't think that's worth the risk of the change.
So I'll go ahead & fix that one.


> [PATCH] Decouple locking implementation from Directory implementation
> ---------------------------------------------------------------------
>
>                 Key: LUCENE-635
>                 URL: http://issues.apache.org/jira/browse/LUCENE-635
>             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 http://issues.apache.org/jira/browse/LUCENE-305.
> 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:
>   http://issues.apache.org/jira/browse/LUCENE-305#action_12418493
> 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 "org.apache.lucene.store.FSDirectoryLockFactoryClass"
>     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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message