jQuery in Action, 3rd edition
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes RandomAccessFile Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "RandomAccessFile" Watch "RandomAccessFile" New topic


Christy Keane
Ranch Hand

Joined: Mar 29, 2005
Posts: 32

I've a fairly general question regarding the use of RandomAccessFile in the context of my SCJD assignment.

Currently, each of my clients has it's own RandomAccessFile object to access the datafile.

To update a record, my business logic executes like this:

My locking implementation prevents more than one client updating the same
record at the same time.

However, more than one client may update different records at the same time.

Is this valid?

Can two or more clients write to different parts of the datafile concurrently?

I'ld appreciate any views people might have.

David Sham
Ranch Hand

Joined: Apr 19, 2005
Posts: 61
Yes they can. You can have 2 or more clients updating the database file simultaneously, but each client updating different records in the file. Nothing wrong with that, since the records being updated are all different, there is no danger of data corruption.

The locking mechanism should only be concerned with 2 or more clients trying to update or delete the same record simultaneously. Otherwise, data corruption would occur if this happened.
Ian Wark
Ranch Hand

Joined: Jun 28, 2004
Posts: 37

If we were talking about SQL this would be the case. Perfectly fine. No worries at all. Efficient too.

The problem is that it is a RandomAccessFile. A RandomAccessFile has one file pointer and content that is like a large array of bytes.

Say client one updates record 8 and client two reads record 12 at the same time. What do the operations look like? They look like this:

1. Move the file pointer to the correct location.
2. Update or read.

So what happens if the client updating record 8 slices out half way through writing the record and the client reading record 12 starts? If we are unlucky the file pointer will be moved by the record 12 read operation. Then when our write operation slices back in it continues writing the remainder of the update to just after record 12. There is nothing to stop this, unless we make all access to the RandomAccessFile one by one.


If anyone can explain how this is not the case I am all ears.
Ian Wark
Ranch Hand

Joined: Jun 28, 2004
Posts: 37
Let me put what I just said above into more perspective.

I overlooked the fact that Christy has one RandomAccessFile for each client. It seems to me that this would work, as long as multiple instances of the RandomAccessFile have totally independent file pointers. If all instances point at the same location, however, the bad scenario I describe in the post above would seem possible.

If the person is using channels, the above bad scenario I believe would be true, since multiple instances seem to have the same fundamental file pointer. The channel API states:

The view of a file provided by an instance of this class is guaranteed to be consistent with other views of the same file provided by other instances in the same program.

But channels are a totally different thing to a RAF. Hmmm..
Ian Wark
Ranch Hand

Joined: Jun 28, 2004
Posts: 37
Feel like a one man show here..

I may be wrong about the file channel implementation having the same file pointer for each instance. The API only states that it is intimately connected only to the instance on which getChannel was called. That is, the instance of RandomAccessFile on which it was called.

Christy, I think your idea is probably a goer. If it is not, the consequences are so drastic that I do not believe it would be possible to fulfill the requirements for our projects. I am going to go with it. I have no more time to spare. Good luck!
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
I've implemented a pool of Random Access File instances. I then implemented a test case which proved that it was possible for different parts of the data file to be written to and read from concurrently. As long as you provide a mechanism to prevent reading and writing to same part of the file simultaneously you should be ok at least for WinXP.
I agree. Here's the link: http://aspose.com/file-tools
subject: RandomAccessFile
It's not a secret anymore!