FileLock and file access from concurrent threads..

[fxRichard]

...the javadoc for the FileLock class states the following:

"...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.

File-lock objects are safe for use by multiple concurrent threads...."

Yet when I apply a lock to a file I am getting access issues from within the same program. The program is heavily multi threaded and it will be a pain to have to release the lock in order to read/write from another thread etc and then reapply the lock etc. Does anyone have any input on this or experience this? Thanks!

[Nicholas Jordan]

Basic answer is that it is as complicated as your post suggests, have you tried nio? I rejected the package at first read because I was not ready for that depth, I am now beginning to use it. Matters like this is why it came to be, there are some issues buried in implementation that suggest trying the nio package first if app is heavy on the threads.

I seem to grasp threads before I grasp anything else, file locking may be simplified by putting the file access in a synchronized block - at one point in the program ( perhaps a dedicated class for that purpose ) then instanciating the wrapper where ever you need a file and doing synchronized{......} at the access point.

Here's code I wrote an hour ago:

    public final synchronized String getString(Boolean vector, String value, Integer index)

without the do-dads, put a doormat that says 'uh-oh' by your coffee machine.

[fxRichard]

I appreciate the response. What is interesting is in a test class everything works great but in my software I am getting:

"The process cannot access the file because another process has locked a portion of the file"

When I comment out the call to the method that locks the files everything works great so I know it's due to the fact that I have locked the file. A workable solution would be to release the lock before accessing the file then reapplying etc however this is a huge task do to the complexity of the software as we are talking about a lot more than just 1 file with one location in the code to read/write etc. Oh and as for the nio package that is what I am using:

java.nio.channels.FileLock; and FileChannel

I ruled out a few possbilities such as the first call to access a locked file comes from a static method (thought maybe Java was somehow handling the static method in a way that would cause it to fall out of the realm of "same program" etc.) and ran the same code from a test class that replicates what I am doing (just much simpler) by creating a dummy thread that accesses the file and a dummy static method etc.... all work in this case......hmmm makes me think something else is going on but when debugging it's the first line of code that attempts to read data from the locked file that throws the exception with the message above. lol sorry for such a long post.

[Nicholas Jordan]

this is a short post to me, just enough to get the details.

What version jvm?

I have worked those fallout issues, still believe them, but 5 and later have supposed to addressed the concurrency issues. Recently, I have had several issues that were resolved by moving declaration and new in or out a scope or two, being sure to force an actual new on each iteration of a loop.

Been doing pre-alpha for two days, going back down to data storage and writing rtf or finding something not as bloated as xml because I think I have the problem isolated and boxed, ready for display in the foyer. The approach worked several times.

[fxRichard]

I am using 1.6.xxx don't remember I think update 10. Unfortunately I had to create a workaround, I am almost positive this is an error with Java as I have ruled out all other possibilities. Either way I created a workaround for now, not the ideal solution but it works, the temp solution was to extend the FileInputStream and FileOutputStream , override the constructor to take a FileLock object that the inputstream uses to unlock and lock the file when necessary. Unfortunately the new class has to be created by the class that created and holds the lock, for instance:

LockableInputStream = SomeClass.getLockableInputStream(new File("some.file"));

where SomeClass created and holds the FileChannel and/or FileLock created by the FileChannel thus in SomeClass it's code would look something like this:

public LockableInputStream getLockableInputStream(File file)
{
return(new LockableInputStream(file, theFileLockICreated));
}

[Nicholas Jordan]

synchronize on this in the override, ......

uh, how many places in the code would have to be re-designed to take the override you already wrote?.. dozens, hundreds?.. that's not workable.

By re-design the File override, all that need be done is place one synchronized(this) on entry, the real trick is going past contemporary design practice of synchronizing on a Lock Object, thus:

class FileClass{ private Object Lock;
public get(){....
public set(){....

the fix, though not generally recognized in contemprary literature, is to do get(boolean set, retrieve, some action, which design leads to other issues., notably in that having one call signature for read and write, the method must return a data object, that makes confirming the boolean sucess of the call dicey at best.

It's a battle, I recognize this. I was up a 4am this morning fixing that in my own code.

The central office called just now, they want to know where everything is.

To shorten it up, place *all* calls to file on one call to new - somewhere early in program init(); Propogate the object either in constructors or in a get call for the file object that returns this. Then put a synchronized(this) at an outer scope in the file object. To do otherwise will have the Office Above giving Hell from Above.

See Servlet design, that is a good design. It addresses the issue well if one reads up on how to do that correctly on demand load,... some sort of feed-forward design.