Not having to assign index readers a write permission in the index dir is a nice feature, I didn't think of it that way.
I looked at having it the other way around - i.e. that by default locks would be maintained in the index dir and only when inadequate - like the readers/writers scenario, allow to override with an equivalent of setLockPath. But (1) now reader would write in the index dir; (2) might be that there are more use cases like the latter; and (3) anyhow a setLockPath method would be required. So it seems to me best not to change this. - Doron > : Doug explains the rationale here: > : > : http://xrl.us/svsz (Link to mail-archives.apache.org) > > That rationale makes a lot of sense for FSDirectory/SimpleLockFactory to > use by default (since it already doesn't work in a distributed disk > system like NFS) but as we start getting other Directory/LockFactory > implementations which may not have these problems, we need to make sure > that those new classes aren't limited by this. > > My initial thought was that this would be something the lockFactory > already had control over, but then i realized this is really driven by > Directory.getLockID, and LockFactory.setLockPrefix ... it looks like > perhaps newer LockFactories that can work on distributed drives might need > to have non-trivial setLockPrefix methods that ignore their input. > > Either that or we punt on the issue and just have really good > documentation to the effect that apps on systems using shared drives need > to call lockFactory.setLockPrefix explicitly. > > > > -Hoss > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
