Reading while writing

[Crouchez]

If there's a java process writing to a file and another java process reading
from it - what happens? Does the reader take it what's currently been
written or what? Does the OS deal with this in some way - like giving a
before-write copy of the file?

 

[Joshua Cranmer]

If there's a java process writing to a file and another java process
reading from it - what happens? Does the reader take it what's currently
been written or what? Does the OS deal with this in some way - like
giving a before-write copy of the file?

It depends on the OS (or, more likely, the filesystem driver). Most
filesystems would probably hold a read-write lock on the file, creating a
race condition.

 

[Crouchez]

It depends on the OS (or, more likely, the filesystem driver). Most
filesystems would probably hold a read-write lock on the file, creating a
race condition.

So there's most likely a block on the file? Doesn't seem the best way of
dealing with the situation. A guess we're going under java here a bit?

 

[Mark Space]

It depends on the OS (or, more likely, the filesystem driver). Most
filesystems would probably hold a read-write lock on the file, creating a
race condition.

I think most filesystems would throw an error, or more likely, scramble
the data.

The application should employ locking to ensure that a region of a file
is changed in an orderly manner. Java NIO has a FileLock object. Try that.

 

[Lew]

I think most filesystems would throw an error, or more likely, scramble
the data.

The application should employ locking to ensure that a region of a file
is changed in an orderly manner. Java NIO has a FileLock object. Try
that.

There was a recent thread discussing that Java file locks may be advisory
only, depending on how the underlying OS implements file locks.

 

[Mark Space]

There was a recent thread discussing that Java file locks may be
advisory only, depending on how the underlying OS implements file locks.

Write once, test everywhere. Just great. The Java Doc says this about
FileLock:

" Whether or not a lock actually prevents another program from accessing
the content of the locked region is system-dependent and therefore
unspecified. The native file-locking facilities of some systems are
merely advisory, meaning that programs must cooperatively observe a
known locking protocol in order to guarantee data integrity. On other
systems native file locks are mandatory, meaning that if one program
locks a region of a file then other programs are actually prevented from
accessing that region in a way that would violate the lock. On yet other
systems, whether native file locks are advisory or mandatory is
configurable on a per-file basis. To ensure consistent and correct
behavior across platforms, it is strongly recommended that the locks
provided by this API be used as if they were advisory locks. "

Which to me implies that one should test for a lock first. Writing data
to a locked region and expecting an error to be thrown may not produce
an exception, just bad data. So it should all still work, you just have
to test for locks first. Correct?

 

[Roedy Green]

If there's a java process writing to a file and another java process reading
from it - what happens? Does the reader take it what's currently been
written or what? Does the OS deal with this in some way - like giving a
before-write copy of the file?

A mess. The file will look to the reader the length it had at the last
flush or close.

For than sort of thing you normally use a TCP/IP stream.

 

[Crouchez]

you see, this has always got me about java development - there's always one
eye on the os platform - the java layer always depends on what's going on
underneath - and much of the time you won't have a clue - most of the meaty
stuff is closed off in native methods

 

[Esmond Pitt]

Lew wrote:

To ensure consistent and correct
behavior across platforms, it is strongly recommended that the locks
provided by this API be used as if they were advisory locks. "

Which to me implies that one should test for a lock first. Writing data
to a locked region and expecting an error to be thrown may not produce
an exception, just bad data. So it should all still work, you just have
to test for locks first. Correct?

Correct. And note that Unix 'mandatory' locks, where implemented, would
only have made the situation worse. With Unix mandatory locks, if the
writer hadn't tried to acquire the lock first, the write would be merely
*delayed* until the lock was released by whoever had it, *ensuring* a
data corruption (because the non-cooperative update occurred after the
cooperative update). By contrast, that non-cooperative write() on a
Windows machine would have given an error immediately, which is the only
sensible behaviour. You must always test and set file locks in all parts
of an application that want to share a file, and *never* rely on Unix
mandatory locking even when you know it exists.