aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: Saving the database Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX: Saving the database" Watch "NX: Saving the database" New topic
Author

NX: Saving the database

Charlie Goth
Ranch Hand

Joined: Feb 26, 2004
Posts: 60
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


SCJP (77%)
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi 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.


Regards, George
SCJP, SCJD, SCWCD, SCBCD
Mogens Nidding
Ranch Hand

Joined: Mar 08, 2004
Posts: 77
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.
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi Nicky,
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 ]
Charlie Goth
Ranch Hand

Joined: Feb 26, 2004
Posts: 60
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
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi Charlie,
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: NX: Saving the database