lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doron Cohen <>
Subject Re: lock path thoughts
Date Tue, 31 Oct 2006 01:59:15 GMT
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:
> :
> : (Link to
> 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
> 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:
> For additional commands, e-mail:

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

View raw message