«

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?

On Thu, 19 Jul 2007 23:54:03 +0000, Crouchez wrote:

> 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.

"Joshua Cranmer" <> wrote in message
news:%fUni.6843$ct5.5506@trnddc06...
> On Thu, 19 Jul 2007 23:54:03 +0000, Crouchez wrote:
>
>> 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.

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?

Joshua Cranmer wrote:
> On Thu, 19 Jul 2007 23:54:03 +0000, Crouchez wrote:
>
>> 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.

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.

Mark Space wrote:
> Joshua Cranmer wrote:
>> On Thu, 19 Jul 2007 23:54:03 +0000, Crouchez wrote:
>>
>>> 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.
>
> 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.

--
Lew

Lew wrote:

> 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?

On Thu, 19 Jul 2007 23:54:03 GMT, "Crouchez"
<> wrote, quoted or indirectly
quoted someone who said :

>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.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

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

Mark Space wrote:

> 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.