file locking questions

[Avinash Lakshman]

Maybe this is slightly off topic but wouldn't the addition of large array
support be great here. I am assuming that RAM file system in the VFS can
only use files that can get as large as 2 GB since is is maintained using
some sort of an array addressed using an int. If the machine has large
amount of memory I am assuming that one would need to maintain multiple 2 GB
file systems in order to use the memory more effectively. Wouldn't this be a
good use case for providing large array support so that RAM file system
could hold files as large as permissible memory? I am new to this VFS thingy
so if I am way off please correct me.
Avinash

On Sun, Aug 23, 2009 at 9:18 AM, Alan Bateman <Alan.Bateman at sun.com> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20090823/482032fe/attachment.html