How good is good enough?

[John Lee]

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]

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

[John Lee]

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]

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]

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]

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