I you may be overcomplicating the lock design. Unix never had any OS
file locking at all (until Windows came around...).
If you are going to use Lucene in a high performing multi-user/multi-
server environment, having the Lucene server process control the
locks (i.e. move Lucene API into a server process) will give FAR
better through-put, and easier manageability. If you are not using
this, then the simple existing file based locks should be more than
adequate.
Even if you want to span the index over several NFS volumes, you
should have a front-end controller, (or controller per volume) that
can communicate the locks if needed.
Using the filesystem/OS to manage the locks is simple, but inferior
in almost all cases, especially if you want to increase the
parallelism of the backend - you ordinarily need much finer lock
control than an OS will provide.
The nice things is... as long as 'disable locks' is always supported,
I'll be happy :)
Just my thoughts.
Robert
On Oct 30, 2006, at 6:14 PM, Chris Hostetter wrote:
: 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]
