lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert engels <reng...@ix.netcom.com>
Subject Re: lock path thoughts
Date Tue, 31 Oct 2006 00:29:00 GMT
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: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message