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.
-- - Mark http://www.lucidimagination.com
