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!
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.
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 .
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 ]
Anton Golovin (firstname.lastname@example.org) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]