Reading Files - Beginning Java - page 538

shared lock on the file. Some operating systems do not support shared locks, in which case the request is
always treated as an exclusive lock regardless of what you requested. Microsoft Windows 7 supports shared
locks.
Note that a single Java Virtual Machine (JVM) does not allow overlapping locks, so different threads
running on the same JVM 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 prob-
lem for you then the safe thing to do is to obtain an exclusive lock on the file you are working with. If you
want to test for the presence of an overlapping lock, you can call the overlaps() method for your lock ob-
ject.
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 some instances, though, you should use
exclusive locks because external changes to a file's contents can still be a problem even when the parts you
are accessing cannot be changed. As I've said, you can obtain an exclusive lock only on a channel that is
open for both reading and writing; a NonReadableChannelException or NonWritableChannelException
is thrown, as appropriate, if you have opened the file just for input or just for output. This means that if you
really must have an exclusive lock on a file, you have to have opened it for reading and writing.
You don't need to obtain a 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 ne-
cessary, 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
example, you need to lock the entire file. Any changes made 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 when you are done with it. You can get an idea of how you might do this in the context of the program
that lists the primes from the primes.bin file.
TRY IT OUT: Using a File Lock
You will lock the region of the primes.bin file that you intend to read and then release it after the read
operation is complete. You will use the tryLock() method because 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 you need to be
able to pause the current thread rather than roaring round a tight loop frantically calling the tryLock()
method. I bring forward a capability from Chapter 16 to do this for you. You 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();