[ http://issues.apache.org/jira/browse/LUCENE-635?page=comments#action_12431341 ] Doron Cohen commented on LUCENE-635: ------------------------------------
While updating my patch for 665 according the changes here, I noticed something - I may be wrong here - but it seems to me that until this change, all the actual FS access operations where performed by FSDirectory, using the Directory API. The new SimpleFSLock and SimpleFSLockFactory also access the FS directly, not through FSDirectory API. That Directory abstraction in Lucene allows to develop Lucene-in-RAM, Lucene-in-DB, etc. It is a nice feature. Guess we can say: "well, now the abstraction is made of two interfaces - Lock and Directory, just make sure you use 'matching' implementations of them." This seems weaker than before. Or, can limit all file access to go through FSDirectory - - one possibility is to add to LockFactory a Directory object (as a class member); SimpleFSLockFactory can require thas Directory object to be FSDirectory (cast, and fail otherwise); also, FSDirectory should be extened with createSingleFile(), mkdirs() and isDirectory(). > [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 > 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 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]
