Mark Miller wrote: > Chris Hostetter wrote: > >> : > 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 >> >> >> > I've got more info on this. > > Checking for OverlappingFileLockException *should* actually work when > using Java 1.6. Java 1.6 started using a *system wide* thread safe check > for this. > > Previous to Java 1.6, checks for this *were* limited to an instance of > FileChannel - the FileChannel maintained its own personal lock list. So > you have to use > the same Channel to even have any hope of seeing an > OverlappingFileLockException. Even then though, its not properly thread > safe. They did not sync across > checking if the lock exists and acquiring the lock - they separately > sync each action - leaving room to acquire the lock twice from two > different threads like I was seeing. > > Interestingly, Java 1.6 has a back compat mode you can turn on that > doesn't use the system wide lock list, and they have fixed this thread > safety issue in that impl - there is a sync across checking > and getting the lock so that it is properly thread safe - but not in > Java 1.4, 1.5. > > Looking at GCC - uh ... I don't think you want to use GCC - they don't > appear to use a lock list and check for this at all :) > > But the point is, this is fixable on Java 6 if we check for > OverlappingFileLockException - it *should* work across webapps, and it > is actually thread safe, unlike Java 1.4,1.5. > > Another interesting fact:
On Windows, if you attempt to lock the same file with different channel instances pre Java 1.6 - the code will deadlock. -- - Mark http://www.lucidimagination.com
