B&S: RandomAccessFile contains one file pointer?

[Lek Olof]

Hi,

I was puzzled with following:

I have a RandonAccesFile on the server side which has the access to the db file. Before updating a record I lock it with the lock(int recNo) method.

But what happens when I update a record and the same time another client wants to read some other record and a third record wants at the same time update another record. Since the RandomAccessFile is (and should be??!!) on the server side it has only one file pointer so even if a lock a record to make sure nobody works with that record I still have problems.

If a synchronize the access to the RandomAccessFile there is no point in locking a record it seems since no multiple reads or writes to different records will be possible.

How have you guys solved this issue?

regards
Olof

[Song Jing Lim]

RandomAccessFile object need to be synchronize bcoz user may move the file pointer position during seek()

e.g.
User1: move the RAF seek to locaiton x and writing/reading
at the half way
User2: move the RAF seek to locaiton y for writing/reading

Problem may came out if file position had change during half way of operation.

Am I right? (personaly I also face this problem )

[Cindy Rogers]

Lek,

I considered the locking and synchronization as two related but different functions:

- synchronizing access to the RAF is needed for a single read, update, create, or delete operation, as you stated.

- the locking function ensures that no one else is modifying the specific record while one client is in the process of an update or delete (and I also locked the record during a create). Others may read the record while it is locked -- and because the RAF access is synchronized, the record's data will never be seen partially updated.

For example, when I want to update record 11 which is currently shown on the GUI, I do the following:
1. lock record 11
2. read the current data in record 11. This step also verifies the record is still active.
3. compare the current data to the data which was shown on the GUI. If the data is not the same, I send one of two exceptions depending on the difference (record is no longer eligible to be reserved; record is eligible to be reserved but some attributes have changed).
4. update record 11
5. unlock record 11

Note that the read in step 2 and the update in step 4 are synchronized, but I needed the lock function to ensure the data is not changed by another client between the read and update operations.

I hope this helps.

Cindy

[Lek Olof]

Thanks Cindy, that helped!