Forums Register Login

RandomAccessFile

+Pie Number of slices to send: Send
Hi,

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:
lock();
update();
unlock();

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.

Thanks.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
David,

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.

Ouch!

If anyone can explain how this is not the case I am all ears.
+Pie Number of slices to send: Send
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..
+Pie Number of slices to send: Send
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!
+Pie Number of slices to send: Send
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.
It's never done THAT before. Explain it to me tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 909 times.
Similar Threads
Is this a bad way to approach things?
nx:All of URLy Bird 1.1.3 read/write lock and create()
B&S: RandomAccessFile contains one file pointer?
Is it necessary synchronize on seek?
NX: Is this that bad?
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 23:34:57.