There's a couple of different ways to handle this.

1. do not do it in real time. this is the easiest solution, but it
means a human has to be the one who figures who gets what class.

2. use JMS to update each user's session and make it so that once the
class has no more entries, no one else can add it to their cart. Say
user 1 submits before user 2. if user 1 registers before 2, a message
is sent to the java bean in memory to update the cart

3. process the orders on a first come first serve basis, but do not
gaurantee the person is signed up for it. In the response email state,
"you will get a confirmation of successful regisration."  This is
usually the easiest way to assuming you send confirmation in
reasonable amount of time. This implies the transaction are processed
async with some kind of queue

4. check availability before starting the transaction. this means some
kind of locking at the row level.

I'm sure there are other ways of doing it. Personally, I prefer
handling the transaction on a first come first serve basis and send
out confirmation in reasonable time.

peter



On Mon, 21 Jun 2004 12:37:04 -0700, Mufaddal Khumri
<[EMAIL PROTECTED]> 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]
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to