File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S: RandomAccessFile contains one file pointer? 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 "B&S: RandomAccessFile contains one file pointer?" Watch "B&S: RandomAccessFile contains one file pointer?" New topic

B&S: RandomAccessFile contains one file pointer?

Lek Olof

Joined: Jan 03, 2007
Posts: 10

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?

Song Jing Lim
Ranch Hand

Joined: Feb 11, 2003
Posts: 56
RandomAccessFile object need to be synchronize bcoz user may move the file pointer position during seek()

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 )

Rgds,<br />Song Jing
Cindy Rogers
Ranch Hand

Joined: May 17, 2006
Posts: 31

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.

Lek Olof

Joined: Jan 03, 2007
Posts: 10
Thanks Cindy, that helped!
I agree. Here's the link:
subject: B&S: RandomAccessFile contains one file pointer?
jQuery in Action, 3rd edition