lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: [jira] Commented: (LUCENE-305) [PATCH] Lock Framework - allows custom lock mechanism
Date Thu, 29 Jun 2006 21:16:40 GMT

> I don't really know/understand a lot about the current internals of Lucene
> Locking ... but based on the writeup you've added to Jira, your plan of
> attack seems like a sound refactoring approach.
> Your choice to use explicit setters instead of a system properties seems
> to make sense given some of the other semi-recent API changes to eliminate
> the use of system props in lucene (personally i think having both setters
> and system props is cool ... but it doesn't seem like anything about your
> approach would prevent a irectory implimentation from using a sys prop if
> it wanted to)

Yes, this is very much a refactoring, for starters.  After this I'd
like to create a NativeFSLockFactory that uses native OS locks to
prevent the "lock timeout" errors when the JVM previously had a hard
shutdown and to work across remote filesystems (though there's at
least one case where this may not have worked correctly over NFS; not
sure about Samba mount).

If that proves reliable we could eventually make it the default
locking for FSDirectory.

I like the idea of both setters & system props.  So, if the setter is
called, we use that LockFactory.  Else, if a system prop is set, we
use that LockFactory.  Else we fallback to the original default
LockFactory implementation (to keep backwards compatibility).  I'll
take this approach.

Also: apparently Jira does not allow issues to be renamed?  I had
wanted to rename LUCENE-305 this "decouple locking implementation from
directory implementation".


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message