Answers
Nov 17, 2009 - 02:42 PM
Good question...I guess the simplest answer is: whoever gets their order in first gets the ticket.
Given the very remote chance that the two users would click the "buy now" button and the very same millisecond utilizing a timestamp for the button click could be the way to solve the "tie" betwen the two.
Let's look at how this could flow...
Assumption #1: All ticket inventories are being held in a database.
Assumption #2: Multiple users can view all tickets available until a ticket has been purchased and is removed from the available inventory count.
Assumption #3: A ticket can only be purchased once and only by a single user.
User A is looking at a ticket for Row A, Seat 1. User B is looking at the same ticket. Both of them decide to purchase Row A, Seat 1.
Once they've clicked the "Buy Now" button, both users are potentially buying the same seat, a clear violation of Assumption #3. Now it's a race to see who can complete the transaction first.
This is where maintaining timestamps comes into play, as well as transactions when dealing with your database.
For the sake of argument, let's say User A clicked the button at 12:00:00:123 and User B clicked the button at 12:00:00:456...it's easy to say that User A wins and gets the ticket. But, User A has not technically completed the purchase - they haven't paid for the ticket.
User B is a bit more on the ball, and even though he clicked the button later than User A to start the process, he has paid for the ticket at 12:00:01:000 and User B completes the payment at 12:00:01:875 which means that User B is the winner and has claim to the ticket.
At this point, you will need to "rollback" User A's purchase, including refunding the money and presenting them with an error message stating the ticket has been purchased.
User B will be presented with the appropriate receipts and confirmation messages to indicate the successful purchase of the ticket.
Yes, it's a lot of comparison within your business logic, but it also prevents a couple of issues: 1) Locking issues at the database can be problematic and actually freeze a system rendering it useless, and 2) it prevents User A from "squatting" on a ticket preventing other interested parties from purchasing it.
I know this is a complex issue you're dealing with, so feel free to follow up here or you can look me up on the web at http://www.castagna.net.
Given the very remote chance that the two users would click the "buy now" button and the very same millisecond utilizing a timestamp for the button click could be the way to solve the "tie" betwen the two.
Let's look at how this could flow...
Assumption #1: All ticket inventories are being held in a database.
Assumption #2: Multiple users can view all tickets available until a ticket has been purchased and is removed from the available inventory count.
Assumption #3: A ticket can only be purchased once and only by a single user.
User A is looking at a ticket for Row A, Seat 1. User B is looking at the same ticket. Both of them decide to purchase Row A, Seat 1.
Once they've clicked the "Buy Now" button, both users are potentially buying the same seat, a clear violation of Assumption #3. Now it's a race to see who can complete the transaction first.
This is where maintaining timestamps comes into play, as well as transactions when dealing with your database.
For the sake of argument, let's say User A clicked the button at 12:00:00:123 and User B clicked the button at 12:00:00:456...it's easy to say that User A wins and gets the ticket. But, User A has not technically completed the purchase - they haven't paid for the ticket.
User B is a bit more on the ball, and even though he clicked the button later than User A to start the process, he has paid for the ticket at 12:00:01:000 and User B completes the payment at 12:00:01:875 which means that User B is the winner and has claim to the ticket.
At this point, you will need to "rollback" User A's purchase, including refunding the money and presenting them with an error message stating the ticket has been purchased.
User B will be presented with the appropriate receipts and confirmation messages to indicate the successful purchase of the ticket.
Yes, it's a lot of comparison within your business logic, but it also prevents a couple of issues: 1) Locking issues at the database can be problematic and actually freeze a system rendering it useless, and 2) it prevents User A from "squatting" on a ticket preventing other interested parties from purchasing it.
I know this is a complex issue you're dealing with, so feel free to follow up here or you can look me up on the web at http://www.castagna.net.
Nov 17, 2009 - 02:46 PM
Aw, rats...didn't proofread my answer close enough...
Restating the paragraph that starts with "User B is a bit more on the ball...":
"User B is a bit more on the ball, and even though he clicked the button later than User A to start the process, he has paid for the ticket at 12:00:01:000 and User *A* completes the payment at 12:00:01:875 which means that User B is the winner and has claim to the ticket.
As stated correctly, User B is successful in the purchase while User A has the transaction "rolled back" as a result of the unsuccessful purchase attempt.
Sorry for the confusion...
Restating the paragraph that starts with "User B is a bit more on the ball...":
"User B is a bit more on the ball, and even though he clicked the button later than User A to start the process, he has paid for the ticket at 12:00:01:000 and User *A* completes the payment at 12:00:01:875 which means that User B is the winner and has claim to the ticket.
As stated correctly, User B is successful in the purchase while User A has the transaction "rolled back" as a result of the unsuccessful purchase attempt.
Sorry for the confusion...
Dec 15, 2009 - 06:40 AM
The question looks to be abandoned by the user who asked it. If no action is taken within 2 days, a Quomon Moderator will consider closing the question and distributing the points.
The Quomon Team
The Quomon Team
Add New Comment