aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes persistence layer Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "persistence layer" Watch "persistence layer" New topic
Author

persistence layer

Enrico Mannarino
Ranch Hand

Joined: Dec 14, 2001
Posts: 133
Hi,
I wrote something yesterday about the db.db file, but I think I wasn't clear enough what I meant so I will try again.
My problem with the db.db file is that I consider it to be a description file more than a database. It contains
1)a description of all flights that exists
2)the number of seats available defines number of seats in the airplane; i.e. small or big plane
3)you shouldn't modify it
Every time you run your tests it should always be the same at the start, so it will give you the same result; i.e. if you're using Junit or equivalent. If this file is "read-only" you should never write to it. I that case most of the methods in the Data class aren't needed.
So what happen when you book a flight? You should reduce number of seats available for that particular flight. If you can't modify the db.db file I see only two options to do this:
1)either do in memory
2)create a new file for the bookings
But I haven't seen any requirements that you're bookings should be stored in a persistence layer. We all agree?
What troubles me is that I have the feeling that Sun wants me to store records in the db.db file without modifying it; i.e. "At present, a basic data storage and retrieval system (the "database") has been implemented and shown to work by the undergraduate". How is that possible?
For me the db.db file is just read-only for the users of the application. I could be write allowed for a system administrator if a flight I added/modified/deleted by a company.
For me it doesn't make sense to write your bookings into the db.db file, except if you just want to modify the seats available field. But in that case, it will be modified=not allowed.
So my question is, how do you, fellow javarachers, see the persistence layer and the db.db file? Who will add records into it, modify it?
Hope for many answers
Enrico Mannarino
HenkGijsbert
Greenhorn

Joined: Jan 07, 2002
Posts: 28
Enrico,
Imho your application SHOULD write in the db.db file. However keep a copy of the original, so when you do the assignment upload, you send the original version.
Regards,
Henk
Enrico Mannarino
Ranch Hand

Joined: Dec 14, 2001
Posts: 133
Hi Henk,
Thank your for your quick reply. But as I said, "For me it doesn't make sense to write your bookings into the db.db file, except if you just want to modify the seats available field".
Do you add records in db.db or do you just update it?
Also, why do say that I SHOULD write to this file? I can't see any requirements for this.
Enrico Mannarino
HenkGijsbert
Greenhorn

Joined: Jan 07, 2002
Posts: 28
Hi Enrico,
The way I see it, when you book x seats on a flight the number of available seats of that flight is diminished with x in db.db. Literally it is never stated explicitly that you SHOULD write into the db.db, but imho it certainly is the most easy and only convenient way to do it. Maybe you think more complex than you need to for this assignment.
Regards,
Henk van Jaarsveld
Enrico Mannarino
Ranch Hand

Joined: Dec 14, 2001
Posts: 133
Hi Henk,
You're perfectly right that I thought this assignment was something that actually could work in a production situation, but it's not.
Anyway, I do agree with you that the approach of just modifying the field Seats available is OK. What I don't like about is that the tester just can run the test once with the same file, after it is "corrupted". One solution of this is to make a copy of it every time you start and use this temp file of db.db instead of the real one.
Thanks for your help!
Regards/
Enrico Mannarino
Enrico Mannarino
Ranch Hand

Joined: Dec 14, 2001
Posts: 133
It would be great if someone else also could have an opinion on this matter! Like Mark for instance!
I appreciate a lot the comments from Henk, but I am a bit surprised that no one else think this is a major question.
Regards
Enrico Mannarino
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

My 2 cents. The only time I change any data in the db.db file is when someone books a flight. That would be changing the available seats total.
If you do not change the db.db file, how do you handle two clients booking for the same flight. Client A books all the remaining seats, then Client B tries to book a seat. If client A does not change the db.db file, then it will allow client B to book a seat, even though there are none left.
Like Heng said, keep a copy of the original db.db file, you will need it when you submit the assignment.
As far as adding or deleting records, that is not in the specs, and not needed. I think those methods are there from the old days when the assignment came with a text file with data, and you had to write a conversion program to import the data into the db.db file, and you needed to use the addRecord method of the Data class.
Otherwise, I would worry about them.
Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Enrico Mannarino
Ranch Hand

Joined: Dec 14, 2001
Posts: 133
Hi Mark,
Thank you for answering yesterday! About your remark about concurrency the answer is: in memory. You don't need to update the db.db to solve this assignment. At startup you'll read all the records in db.db and then put the DataInfo objects in a Vector. You do lock and unlock, but the modify method with not change the database but the DataInfo object concerned.
I think it will be faster and more simple as well, but I'll stick to the good old db.db anyway.
Enrico Mannrino
Gregory Garrison
Ranch Hand

Joined: Oct 05, 2001
Posts: 107
Enrico - according to the specs (reading between the lines) you should update the db.db. You could update the vector only but this will not suffice for the assignment.
Enrico Mannarino
Ranch Hand

Joined: Dec 14, 2001
Posts: 133
Hi Gregory,
"Enrico - according to the specs (reading between the lines) you should update the db.db."
If think that Sun have done a wonderful job.;( Now we have to read between the lines in a spec!
No offence, Gregory, but I do not read this. Ok, I do agree that's what they want us to do, but what a specification.
In real life, not a single line of code would have been written with such a specification! It's just one thing to do with such a specification - back to marketing! Rewrite!
Enrico Mannrino
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

The user must be able to book one or more seats on a chosen flight. If the flight cannot provide those seats, the user must be informed. It is not necessary to provide for live updates on multiple clients when new bookings are made at other clients

If the flight cannot provide those seats. As in you tried to book more seats than were available. If Client A books all the seats, should Client B be able to book seats on the same flight too, when none are now available.
The second part leaves some confusion, but Literally it states that if Client A books those Seats, Client B does not have to see the decrease in seats automatically. He could get them by re-searching and refreshing his data via a search.
As a customer I don't want to book a seat only to find out when I arrive at the airport there really wasn't any seats remaining.
Mark
Enrico Mannarino
Ranch Hand

Joined: Dec 14, 2001
Posts: 133
Hi Mark,
I understand what you're saying and I agree. But I don't understand why you're saying it. You can choose to update the db.db file or do it memory, the application will have the same behaviour.
Also, this application will never be used because it's totally useless in the real world. So I shouldn't bother with that. It would have been nicer if Sun would have come up with a specification that could be realistic, maybe harder but much more fun. Because, who wants to spend time of doing something that never will be in production?

Enrico Mannrino
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

You can choose to update the db.db file or do it memory

What we keep saying to that comment is no, you can't do it in memory because the other clients will book phantom seats that don't exist. That was the original question right? Or did I lose something there.
Mark
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: persistence layer