file locking questions

[Alan Bateman]

Vince Bonfanti wrote:
> :
>
>  1 ) What, if any, are the expectations related to locking by the file
> system when a file is opened for reading and/or writing? Is the file
> system expected to do any automatic locking, or is the user expected
> to do all locking explicitly? Is this behavior file system dependent?
>   
Yes, it is provider specific and there is no requirement to do automatic 
locking. If you have control over this then you might consider 
implementing it without any automatic locking or else support 
provider-specific OpenOptions to allow the application control the 
locking/sharing mode where needed. Our default provider on Windows does 
this to allow for interoperability, where required, with native programs 
that use legacy DOS sharing. If you don't have automatic locking then it 
allows several applications to open the same file for read/write and to 
use the file locking API to coordinate access (important if a file is 
used as a database for example).

>  2) Why is it that SeekableFileChannel must be cast to FileChannel to
> get access to file locking? This implies that support for locking is
> optional or file system dependent--is that the intention?
>   
Yes, this is intentional and meant for the cases where advanced features 
(like memory mapped I/O, positional read/write, or file locking) are 
required. The assumption is that these advanced features can't be 
feasibly implemented by all providers.

One other thing to point out is that if an application really wants a 
FileChannel then the simple way is not to cast the SeekableByteChannel 
to a FileChannel but to instead invoke the FileChannel.open method to 
open the file. This delegates to the provider to create the channel 
(which is allowed to throw UOE if the provider does not support file 
channels).

> :
>
> I thought I read somewhere in the JDK API docs that automatic locking
> (or not) is file system dependent; unfortunately, I can't seem to find
> that comment anywhere.
>   
There isn't anything in the javadoc on this. You may be thinking of the 
"Platform Dependencies" section in the FileLock spec where it explains 
that the file locking API may be implemented on systems that use 
mandatory or advisory locking.

> If locking behavior is file system dependent, I'm thinking about
> implementing a scheme with the following characteristics:
>
>  - automatically support a "one writer, many readers" locking scheme
>  - opening a file for writing, either by getting an OutputStream or
> SeekableByteChannel with write access, gets an exclusive lock that
> blocks all other readers and writers
>  - opening a file for reading, either by getting an InputStream or
> SeekableByteChannel with read access, gets a shared lock that blocks
> any writers but allows other readers
>  - setting the "read-only" attribute for a file blocks all writers and
> allows all readers without requiring any locks
>  - support an "no lock" option when opening a file for read and/or
> write access that would allow the user to control locking explicitly
>
> Does this seem like a a reasonable scheme? Or does this violate any
> conventions that I should be following (but can't seem to find
> documented anywhere)?
>   
This seems reasonable, assuming that blocking other programs means that 
attempts to open the file with a conflicting mode will cause a 
reasonable I/O exception to be thrown. Note that our Windows provider 
can be made to work in this way by specifying the provider-specific 
NOSHARE_WRITE option when opening a file for reading, and the 
NOSHARE_READ and NOSHARE_WRITE options when opening a file for writing. 
In addition to considering other reader and writers, you'll also need to 
think about other operations (delete, moveTo, copyTo, etc. while the 
file is in use).

Hopefully this helps. Please keep us updated on the issues you run into 
as you develop this provider.

-Alan.