[ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
