Since everyone else seems to have an opinion on this, I figure that I might as well share mine. :)
A couple things to keep in mind:
(*) Depending on your geographic location, you may have a legal responsibility to make sure that an item listed as available is, indeed, available. In other words, you can't tell a user that an item is available, let them put into their cart, then tell them it's not available when they try to pay for it. This is municipality-specific, but something to keep in mind for those doing cross-border sales.
(*) The requirement you have described is a business-process requirement. It is not technical and therefore, IMHO, should not be satisfied with row locking, transaction manipulation, etc. Satisfy it on the controller level and avoid polluting your model with stuff like this.
My personal inclination (which could change depending on the situation) would be to give users an X minute (logical) lock once something has been put in their cart. If they don't buy it (or indicate they want to keep it) after that time is up, it goes back on the shelf. In other words, treat everything in your inventory like a real object ... if a consumer wants to buy it, give them a pickup-ticket that they can take to the cashier. Ensure that the number of pickup-tickets equals the number of real items in inventory. The primary benefit here is that you'll fail fast instead of promising something that you can't deliver.
(This isn't my idea, BTW ... take a look at TicketMaster when a hot concert goes on sale to see this in action)
justin
At 12:37 PM 6/21/2004, you wrote:
Hi,
I am in the process of writing a webapp that allows users to make a payment and register for a course. Using Apache -- Tomcat --- MySQL.
The question is a design question i guess, unless there is something in Tomcat that I can leverage, which i might not know. I know that this is a design question , but since I am using Tomcat as my JSP/Servlet container and since the participants here are experts in this field , I thought that I might get some good pointers here.
Lets take this scenario:
User 1 and User 2 are trying to register for a course called "Taekwando". The fee for registering is X amount. Also there is another course called "Majagutamba" and it costs Y amount. Both theses courses have exactly 1 seat remaining.
Now lets say user 1 adds both these courses in his shopping cart, and user 2 does the same, since user 1 has not completed his transaction and paid the enrollment table wont have an entry for user1. (The Enrollment table keeps track of which user is enrolled in which course). Therefore both users have both those courses in their shopping carts. Now both of them proceed to checkout. They enter their credit card information and say submit. Both those users make payments and get enrolled for both those courses!!! Which is wrong , since both those courses could only enroll 1 more person, instead two new users were just added.
To avoid the above problem one could implement a singleton synchronized Transaction object that would process shopping cart checkout in a queue. The problem with this approach are:
1. If anything goes wrong with any one transaction, it would hold up the entire queue. (Well we can have some sort of timeouts and take care of that.)
2. Since this is a syncrhonized singleton and if the traffic for registering for the courses is high, this would be a slow process for which the user will have to wait.
Is there a better solution, algorithm, to do this ? Any help is appreciated.
Thanks,
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
______________________________________________ Justin Ruthenbeck Software Engineer, NextEngine Inc. justinr - AT - nextengine DOT com Confidential. See: http://www.nextengine.com/confidentiality.php ______________________________________________
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
