thanks for the heads-up, this is good to know. I've updated http://wiki.apache.org/lucene-java/AvailableLockFactories which I recently created as a guide to help in choosing between different LockFactories.
I believe the Native LockFactory is very useful, I wouldn't consider this a bug nor consider discouraging it's use, people just need to be informed of the behavior and know that no LockFactory impl is good for all cases. Adding some lines to it's javadoc seems appropriate. Regards, Sanne 2010/1/20 Chris Hostetter <hossman_luc...@fucit.org>: > > : > At a minimu, shouldn't NativeFSLock.obtain() be checking for > : > OverlappingFileLockException and treating that as a failure to acquire the > : > lock? > ... > : Perhaps - that should make it work in more cases - but in my simple > : testing its not 100% reliable. > ... > : File locks are held on behalf of the entire Java virtual machine. > : * They are not suitable for controlling access to a file by multiple > : * threads within the same virtual machine. > > ...Grrr.... so where does that leave us? > > Yonik's added comment was that "native" isnt' recommended when running > multiple webapps in the same container. in truth, "native" *can* > work when running multiple webapps in the same container, just as long as > those cotnainers don't refrence the same data dirs > > I'm worried that we should recommend people avoid native altogether > because even if you are only running one webapp, it seems like a "reload" > or that app could trigger some similar bad behavior. > > So what/how should we document all of this? > > -Hoss > >
