This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes How good is good enough? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "How good is good enough?" Watch "How good is good enough?" New topic
Author

How good is good enough?

John Lee
Ranch Hand

Joined: Aug 05, 2001
Posts: 2545
Hi:
In this flight booking process, people can make some errors. The idea case would be: user lock down a record, place a order, then release the record......But in any of these steps, user may elect to click the upper-righthand "X" to close the small window instead of go forward or backward, so I also have the record releasing defined in the window listener.
But I am sure, this is still far from commercial grade application, so at what point we should settle? how good is good enough?
Thanks,
Don
scjp, scwcd
Ian B Anderson
Ranch Hand

Joined: Jun 26, 2001
Posts: 275
Hello,
Just a thought on what you said:
"The idea case would be: user lock down a record, place a order, then release the record......But in any of these steps, user may elect to click the upper-righthand "X" to close the small window instead of go forward or backward"
This wouldn't happen, you should not lock the record until the user has specified the flight and how many seats they want. You wouldn't lock records and then wait for user input.
Also I think as long as you say what could go wrong in your design document along with possible future enhancements to prevent this then you should be fine.
Good luck
Ian


<a href="http://www.INESystems.com/scbcd/" target="_blank" rel="nofollow">http://www.INESystems.com/scbcd/</a> - SCBCD Exam simulator<br /><a href="http://www.INESystems.com/scbcd/" target="_blank" rel="nofollow">http://www.INESystems.com/scea/</a> - SCEA Exam simulator
John Lee
Ranch Hand

Joined: Aug 05, 2001
Posts: 2545
Originally posted by Ian B Anderson:
Hello,
Just a thought on what you said:
[b]"The idea case would be: user lock down a record, place a order, then release the record......But in any of these steps, user may elect to click the upper-righthand "X" to close the small window instead of go forward or backward"

This wouldn't happen, you should not lock the record until the user has specified the flight and how many seats they want. You wouldn't lock records and then wait for user input.
[/B]

If you lock the record after you specify how many seats, then your lock is not much useful, because Data.modify() has taken care of the synchorization. I think the assignment means you need to protect the data integrity--at certain point in the process, when you saw one ticket available, then it means it is available to you, nobody will book it before you do--they won't proceed to that point unless you release the record.

Also I think as long as you say what could go wrong in your design document along with possible future enhancements to prevent this then you should be fine.
Good luck
Ian

Well, in my design, I seperate search and book function, because the possible delay in booking.
The way it works is:
....user look around....when he like a flight, he need to memorize the flight number, then open a new window, type in the flight number, hit button.............at that point, that flight record is locked, a window with that flight information come up, then user type in the number of ticket, hit button..........at that point, record is released.
Ian B Anderson
Ranch Hand

Joined: Jun 26, 2001
Posts: 275
Hello,
I know what you are saying, yes it would be possible for someone to try and buy a ticket that has already been sold. However if you lock after the user has selected a flight and wait for them to enter the number of seats they require then your system could become very slow. What if it took a client 5 minutes to decide how many seats they wanted? This means if they had the lock for 5 mins nobody else could book a seat on this flight during this time.
If you create a timeout then how long should it be? How would you notify the user? - You would have to track client ids and then notify them that they had lost the lock.
Also in Sun's spec it says: "The aim is to ensure that if two customers attempt to book a seat on the same flight concurrently, then the number of available seats will be reduced by two unless there was only one seat remaining, in which case one customer will be advised at booking time that no more seats are available."
Ian
John Lee
Ranch Hand

Joined: Aug 05, 2001
Posts: 2545
Originally posted by Ian B Anderson:
Hello,
I know what you are saying, yes it would be possible for someone to try and buy a ticket that has already been sold. However if you lock after the user has selected a flight and wait for them to enter the number of seats they require then your system could become very slow. What if it took a client 5 minutes to decide how many seats they wanted? This means if they had the lock for 5 mins nobody else could book a seat on this flight during this time.
If you create a timeout then how long should it be? How would you notify the user? - You would have to track client ids and then notify them that they had lost the lock.

Actually, two people can not "book seat concurrently". Naturally, the definition for "book seat" will be Data.modify(), because you didn't book seat until you physically changed the database. And we all know it is impossible to write to database concurrently because of the synchronization underneath the database.
In Sun's spec, it didn't mention "book seat concurrently", only "attempt to book seat concurrently", attempt?--it can be anything leading to "book seat", such as search, read flight information,...
So I think this paragraph didn't provide any technical requirement.

Also in Sun's spec it says: "The aim is to ensure that if two customers attempt to book a seat on the same flight concurrently, then the number of available seats will be reduced by two unless there was only one seat remaining, in which case one customer will be advised at booking time that no more seats are available."
Ian

I don't think this paragraph lead to the spec of lock/unlock either. When two person book one flight ticket each, as long as their request isn't ignored, then for sure, the total number will deducted by two. But as we have known: it is not " X - 2 ", it is " X - 1 - 1 ", privided " X > 1 ".
Don
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Don Liu:
Naturally, the definition for "book seat" will be Data.modify()
This definition of "book a seat" cannot satisfy Sun's concurrency requirements. Although Data.modify() is of course the core part of it, the "book a seat" operation as a whole will have to be coarser grained than that.
- Peter
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How good is good enough?
 
Similar Threads
Record Locking in multi-user
How do i trap the event of a browser window getting closed ?
how to open JSP page in new window in IBM RAD in portal application
1) no cpu cycles 2) book a selected record 3) the general user interface level
Need SERIOUS HELP!!