Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

raf fails to keep synchronous write contract

 
Jon Entwistle
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I have implemented my project using BSD Unix and JDK build 1.4.2 and there are a couple of issues which a have found and do not know where, or even if, I should highlight them:

1) While testing I deliberatly removed the underlying db file (opened in RWD mode) just prior to writing a new record to file to test the exception mechanism. There was no exception thrown, even though the RandomAccessFile contract states that rwd mode requires "every update to the file's content be written synchronously to the underlying storage device". This is clearly not the case. I retested the server on a Linux box with the same result.

2) I tried to open the file in RWS mode to see the effect, which threw the following cryptic exception on attempting to create the file:



I tried this on the linux box. No exception was thrown creating the RWS file, but the app still happily allowed me to update a non-existant file.

From what I can see there is an innconsistency between what the unix file IO mechanisms allow and the documentation of the RandomAccessFile interface.

My question: The application works fine if I do not delete the file. Should I open the database in RWD and ignore this problem or should I bring it to the attention of the assessor? If I do make a note of it should this be in the version text file or elsewhere?

Regards,

Jon
[ July 12, 2004: Message edited by: Jon Entwistle ]
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jon,

I think that for the purposes of this assignment, you are safe to ignore this issue. As this is a JVM issue, you cannot really be expected to code for variations on how the JVM works on different platforms.

More specificially to your assignment, if you are doing one of the later assignments you should have the instruction "You may assume that at any moment, at most one program is accessing the database file". With this assumption, you are safe to assume that no-one will delete the file you currently have open.

Regards, Andrew
 
Jon Entwistle
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,

Thanks for the reply, I will follow your advice.

The truth is that this project is shaking my confidence in the portability of java as I have found an even more worrying bug in both the Linux and BSD JDK.

The db file is at /usr/home/je/suncert/classes/db-1x1.db, however trying



(with an an extra s on the end) returns true - I have no idea why an extra s invokes the bug. I did some more tests and some other random digits had the same effect. Not very impressed I am afraid.

Regards,

Jon
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic