Mark Miller wrote: > Yonik Seeley wrote: > >> On Mon, Jan 18, 2010 at 1:17 AM, Chris Hostetter >> <hossman_luc...@fucit.org> wrote: >> >> >>> : Right... for stock Solr usage (i.e. as long as they don't try to lock >>> : the same thing.) >>> : It is funny that native locks always work across different processes, >>> : but not always in the same JVM though. >>> >>> Actaully, the more i think about this the less i understand it ... why >>> don't native locks "work" within the same VM? ... and by "work" i mean why >>> didn't he just get a lock timeout error? >>> >>> >> Within the same VM, you need the same FileChannel for some reason. >> Lucene uses a static hashmap so that multiple NativeFSLockFactory >> instances will end up using the same FileChannel for locking. But >> multiple webapps obviously breaks that. >> >> -Yonik >> http://www.lucidimagination.com >> >> > Native Locks are obtained at the JVM level - so if you try and lock the > same Channel twice, since the same JVM already has the lock, its granted > again. I don't think it matters if its the same FileChannel or not - you > just can't use Native Locks within the same JVM, as the lock is held by > the JVM - they are per process - so Lucene does its own little static > map stuff to lock within JVM (simple in memory lock tracking) and uses > the actual Native Lock for multiple JVMs (which is all its good for - > process granularity). But obviously, the in memory locking doesn't work > across webapps. > > Also, the javadocs in Lucene are wrong:
/* * The javadocs for FileChannel state that you should have * a single instance of a FileChannel (per JVM) for all * locking against a given file. To ensure this, we have * a single (static) HashSet that contains the file paths * of all currently locked locks. This protects against * possible cases where different Directory instances in * one JVM (each with their own NativeFSLockFactory * instance) have set the same lock dir and lock prefix. */ The javadocs for FileChannel don't say this at all - and this implies that Lucene is doing something that it is not. The javadocs say don't expect native locks to work for locking within a JVM, because it doesn't. And Lucene doesn't try and use the same FileChannel per JVM (it wouldn't help anyway) - Lucene simply attempts to track per JVM locks in a static map (which doesn't work per JVM when you are dealing with different classloaders). -- - Mark http://www.lucidimagination.com
