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.
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.
Joined: Jun 28, 2004
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..
Joined: Jun 28, 2004
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!
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.