you don't necessarily need to lock or synchronize in a "first come first serve" mode. simple put the order into a queue and generate a temporary order id. Once the order goes through, the real order ID is emailed to the user.
peter On Mon, 21 Jun 2004 14:47:52 -0700, Mufaddal Khumri <[EMAIL PROTECTED]> wrote: > > Hi Frank > > I understand this approach. The problem is that the course table has a > field called "maxregistration" if this field is set to -1 it means that > there is no limit. If there is a value in this field, it will be >= 1. > I have another table called Enrollments. This table has courseId, > userId information. It keeps track of what user is enrolled in what > course. I have a waitinglist table which has userId, courseId, > timestamp. It keeps track of what users are waiting to be enrolled in a > course that has met its capacity. The instructor can give override to > users in waitinglist for a table. An override transfers a user from the > WaitingList table to the Enrollment table. This means that at any given > time the enrollment table could have more than "course.maxregistration" > users enrolled for a course. > > Could you give me an example of a constraint that I could put on my > tables so that it does not allow registrations more than > "course.maxregistration"? > > > On Jun 21, 2004, at 12:56 PM, Frank Zammetti wrote: > > > Probably the easiest way to handle this is simply to have a constraint > > on your database that says a record cannot be added if some field is 0 > > (or a unique constraint, depending on how your table is keyed). Then, > > just catch the exception in your code and check to see if it's a > > violation of your rule, then return a message to the user saying the > > class has filled up. > > > > Simply put, don't worry about them putting the class in the shopping > > cart. Make sure you have a note on the site that says they are NOT > > actually registered until the shopping cart is processed. Then, let > > the database handle the concurrency issues (which they are very good > > at!) and you don't have to complicate your code any. > > > > I generally like staying away from database-level rules like this, > > just in case you tie yourself to a particular vendor, but something > > like this is pretty safe, and is tailor-made for such a mechanism. > > > > Frank > > > > > >> From: Mufaddal Khumri <[EMAIL PROTECTED]> > >> Reply-To: "Tomcat Users List" <[EMAIL PROTECTED]> > >> To: "Tomcat Users List" <[EMAIL PROTECTED]> > >> Subject: Design question .. > >> Date: Mon, 21 Jun 2004 12:37:04 -0700 > >> > >> 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] > >> > > > > _________________________________________________________________ > > MSN Movies - Trailers, showtimes, DVD's, and the latest news from > > Hollywood! > > http://movies.msn.click-url.com/go/onm00200509ave/direct/01/ > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > Mufaddal Khumri > Software Developer > Waves In Motion > Phone: 602 956 7080 x 26 > Email: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
