I seem to have used a different implementation for my database than most, I'm reading all the data from file, then storing each record as an object in a HashMap. Only thing is that the only way to save the db is for a user to select save from the menu, which writes all the data back to file, is this acceptable? I could implement a remote 'commit' command to save the db from the client too. Is this whole approach ok, as the file never gets updated until I save it, is there a requirement(s) (explicit or implicit) that I've missed? Thoughts would be appreciated, Thanks Charlie
Originally posted by Charlie Goth: Is this whole approach ok, as the file never gets updated until I save it, is there a requirement(s) (explicit or implicit) that I've missed?
Let's say you have a server S, and two clients C1 and C2. Can each of them (S, C1, and C2) cause the database to be saved? Let's say C3 starts up, makes a couple of updates, and then exits. Then let's say S crashes for some reason. Then C3's updates are lost, aren't they. If you allow clients to force a save then I guess I don't have any objection to your scheme. For example, C4 starts up, makes a couple of updates, causes the database file to be saved, and then exits. Then if S crashes at least C4's changes won't be lost.
As far as I can tell, there is no requirement addressing when the database must be saved. You could just save at server shutdown without violating the instructions. (This it what you asked about, right?) Whether you like the solution or whether it will affect your grade are other questions for which I have no firm answer. You could be concerned about server crashes and consider adding a client-save or autosave feature. But then again, what if your server crashes in the middle of a save operation? I think implementing a backup file strategy would be overdoing it. Robustness against hardware failures is not a requirement, so it's your call.
posted 14 years ago
Originally posted by Nicky Bodentien: As far as I can tell, there is no requirement addressing when the database must be saved. You could just save at server shutdown without violating the instructions. (This it what you asked about, right?)
I have to agree with you. I think one should discuss the consequences of the server crashing in the design choices document and say that such a concern is beyond the scope of the project. I did something similar (that is, point out a concern that I decided was beyond the scope of the project) in my project regarding clients crashing while holding a record lock. You want the examiner to understand that you are aware of potential problems with your design, but it is appropriate to point out where you believe the solution to these problems is beyond the scope of the project. [ March 08, 2004: Message edited by: George Marinkovich ]
SCJP, SCJD, SCWCD, SCBCD
posted 14 years ago
Thanks for the replies. I've noticed this comment on the read method of the provided interface:
[this method] Reads a record from the file. Returns an array where each element is a record value.
This implies I should be reading the file every time, am I reading too much into this comment? Charlie
posted 14 years ago
Originally posted by Charlie Goth: This implies I should be reading the file every time, am I reading too much into this comment?
Perhaps so. The specification implies that the record comes from the file. It doesn't explicitly say when the record was obtained from the file. I think it's possible to interpret this specification such that you would not have to read the record from the file every time the method is called (in other words, using a cache is not prohibited by this specification). The most straightforward interpretation of this specification is that the record should be read from the file every time the the method is called. But I don't think this precludes your using alternate (if less straightforward) interpretations of the specification. If you think that you are making an interpretation that is other than the most straightforward one, then the issue is probably ripe for comment in your design choices document. If you make a reasonable decision about a possibly ambiguous specification and document that decision in your choices document then I think you'll be OK.