Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

RandomAccessFile.length() is not thread save!

 
Tomas Klubal
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I think that it might be interesting for other ranchers to know that RandomAccessFile.length() is not thread save. File pointer is moved during this operation before it is set back to the original position. I have experienced EOFExceptions when retrieving all records even I had seek/read and seek/write operations synchronized.

See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4823133 for details.

Regards,
 
Jonathan Wolter
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In many exam problems, we may assume only one "Server application" -- and if you choose, one thread - is accessing the database file. Do you have an implementation that suggests this thread safety issue is a problem? I must be missing something...

Jonathan
 
Musab Al-Rawi
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
One solution that I can think of is opening a random access file in each method separately. That would solve closing the file and the unsynchronized length().
 
Tomas Klubal
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Musab Al-Rawi:
Hi,
One solution that I can think of is opening a random access file in each method separately. That would solve closing the file and the unsynchronized length().

My solution is to synchronize on the random access file when calling length and assign the length to the local variable before iterating through all records during search.
 
Tomas Klubal
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jonathan Wolter:
In many exam problems, we may assume only one "Server application" -- and if you choose, one thread - is accessing the database file. Do you have an implementation that suggests this thread safety issue is a problem? I must be missing something...

Jonathan

I have implementation that uses multiple threads accessing the same instance of the RandomAccessFile.

For instance while thread A is reading all records to perform search on them, thread B is trying to read (or update or delete) particular record.

I have experienced following:
  • Thread-B sets the file pointer to ie. 192 and is sliced out
  • Thread-A thread calls length() and inside this operation moves the file pointer to the end of the file and is sliced out before it can return file pointer to the original position and finish the length() operation.
  • Thread-B tries to read from the incorect position set by Thread-A and throws EOFException.
  • Thread-A finishes the length() method by setting the file pointer to the original position

  •  
    ciaran_cahill
    Greenhorn
    Posts: 5
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Wouldn't it be best to have a lock for the RandomAccessFile object and enforce a design rule that programmers must acquire this lock before using the object in any way?
     
    Tomas Klubal
    Greenhorn
    Posts: 20
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by CP Cahill:
    Wouldn't it be best to have a lock for the RandomAccessFile object and enforce a design rule that programmers must acquire this lock before using the object in any way?


    Yes,
    that's my solution. Instance of the RandomAccessFile is used as a lock object and every access to it is synchronized.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic