Reading Files - Beginning Java 2 SDK - page 461

The effect of a shared lock is to prevent an exclusive lock being acquired by another program that
overlaps the region that is locked. However, a shared lock does permit another program to acquire a
shared lock on a region of the file that may overlap the region to which the original shared lock applies.
This implies that more than one program may be accessing and updating the same region of the file, so
the effect of a shared lock is simply to ensure your code is not prevented from doing whatever it is
doing by some other program with a shared lock on the file. Some operating systems do not support
shared locks, in which case the request will always be treated as an exclusive lock.
Note that a single virtual machine does not allow overlapping locks so different threads running on the same
VM cannot have overlapping locks on a file. However, the locks within two or more JVMs on the same
computer can overlap. If another program changing the data in a file would cause a problem for you then the
safe thing to do is to obtain an exclusive lock on the region of the file you are working with.
Practical File Locking Considerations
You can apply file locks in any context, not just with memory-mapped files. The fact that all or part of a
file can be locked by a program means that you cannot ignore file locking when you are writing a real-
world Java application that may execute in a context where file locking is supported. You need to
include at least shared file locks for regions of a file that your program uses. In most instances, though,
you will want to use exclusive locks since external changes to a file's contents are usually a problem if
you are accessing the same data.
You don't need to obtain an exclusive lock on an entire file. Generally, if it is likely that other programs
will be using the same file concurrently, it is not reasonable practice to lock everyone else out, unless it
is absolutely necessary, such as a situation in which you may be performing a transacted operation that
must either succeed or fail entirely. Circumstances where it would be necessary are when the
correctness of your program result is dependent on the entire file's contents not changing. If you were
computing a checksum for a file for instance, you need to lock the entire file. Any changes while your
checksum calculation is in progress are likely to make it incorrect.
Most of the time it is quite sufficient to lock the portion of the file you are working with, and then
release it once you have done with it. We can show the idea in the context of the program that lists the
primes from the primes.bin file.
Try It Out - Using a File Lock
We will lock the region of the primes.bin file that we intend to read, and then release it after the read
operation is complete. We will use the tryLock() method, since it does not block, and try to acquire
the lock again if it fails to return a reference to a FileLock object. To do this sensibly we need to be
able to pause the current thread rather than roaring round a tight loop frantically calling the
tryLock() method. We will bring forward a capability from Chapter 15 to do this for us. We can
pause the current thread by 200 milliseconds with the following code:
try {
Thread.sleep(200); // Wait for 200 milliseconds
} catch(InterruptedException e) {
e.printStackTrace(System.err);
}