• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Writing into DB File

 
Daniel Simpson
Ranch Hand
Posts: 181
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, I am implementing my update method in my Data class, and I had a question about writing bytes into the file, that is, overwriting bytes (updating the record). Here is my code:

Basically, here's what happens. It reads through the data[] that was passed into the method. If it is null, I skip the value, meaning, do not update that field. Otherwise, it writes the bytes of data. It checks to see if there were any leftover bytes in the field length. Here is what my doc says when referring to the fields:
All text values, and all fields (which are text only), contain only 8 bit characters, null terminated if less than the maximum length for the field.
So my question is, how do I write null terminating values into the field if there are bytes left over in the field? Thanks for your help!
 
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 Daniel,

All the assignments seem to state that the fields are null terminated. However none of the provided data files contain null terminated fields.

This is the sort of thing you can experience in the real world, where the person writing the specification thinks one thing should be happening, whereas the person writing the other pieces of software expects another thing.

You might be interested in reading the topic "URLyBird 1.3.3 data file: Reply from SUN" for some thoughts on what to do / how to handle this.

On an unrelated topic, have you considered multi user performance in your code? All the code you have listed above must be in a synchronized block or synchronized method, and there are quite a considerable amount of work happening there. No other client could be reading or writing the file while that happens. As an alternative, you could try something similar to:This requires two synchronized blocks to achieve the same thing, but the major work is done in the "modify buffered record according to requirements", during which time other threads (clients) can be reading and writing other records. This would give you greater concurrency.

You might also want to reconsider your naming conventions. dbReader.writeBytes(data[i]); is a bit counter-intuitive .

Regards, Andrew
 
Anton Golovin
Ranch Hand
Posts: 527
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Daniel. I remember pondering over the null-terminated requirement until it hit me that another report application is using the same file for reports. Now, supposedly they are only reading the data, but even then, the fact that the entries are not null-terminated suggests that application may not know how to read null-terminated entries properly... So I think in retrospect this is one of those things Sun injected quite on purpose to test how one deals with supposedly contradictory requirements and reality, but at the same time, they did provide the clue - the report application.

However, when I was actually deciding on this, let me tell you, I had a lot of doubt. This is generalizable: I had a lot of doubt on many things that seemed to address particular details of the implementation. But 1) documenting the choice helps, and 2) there could be clues interspersed in between Sun's requirements for most of these uncertainties.

Hope this helps.
[ November 26, 2004: Message edited by: Anton Golovin ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic