Yes, I could not said it better. I am not using clusters, but I certainly do want to stay away from the singleton and synchronization approach. It does have to be done at the database or with an extra table called "Enrollment_Temp" or something. Basically, when a user adds the course to his cart, an entry would be made in the Enrollment_Temp table and the current timestamp would be written to one column in this table. The current number of enrollments would thus be the sum of such entries in the Enrollment_temp and Enrollment table. If the user completes his transaction this entry from the enrollment_temp table can be moved to the enrollment table. This raises the question that there would be certain users who would not complete their transaction. Such users would cause entries in the Enrollment_temp table. We can have a timeout on the life of such entries in the enrollment_temp table. Have a thread clean the Enrollment_temp table if a condition like "now" > timestamp stored + 30 minutes.

If a user has a course in his or her shopping cart and does not complete his transaction, and if this was the last seat. For the next 30 minutes from the time he adds that course to his shopping cart, it wont be available to anybody.

Q 1. Is this a good approach and is this judicious enough for users to use?
Q 2. Can any improvements made to this approach?


On Jun 21, 2004, at 4:07 PM, Frank Zammetti wrote:

If your thinking in terms of singletons and synchronized blocks, it seems like you are thinking along the lines of doing this all in-memory. You CAN do that, but it's generally not a good idea.

First, I don't know if your dealing with a clustered environment, but if you are you'll find that you have synchronization issues to deal with.

Second, the obvious: if power goes out, everything is lost. If your dealing with a database, there's at least the possibility of recovering things.

Third, any time you introduce a synchronized block in a J2EE-based application you have to ask yourself if your design isn't flawed because you are supposed to let the container handle all threading issues and your code should always be thread-safe. I myself have broken this rule on occassion, and I believe it to be valid to do sometimes, but you need to be sure it's truly the right anwer.

Assuming you decide it is, realize that any synchronized block of code means your introducing a bottleneck to the application. You may decide it's insignificant, but you are essentially serializing all requests that go through that critical section, so you need to really make sure it's the right thing to do. In a recent app, I had a critical section during logon. This is very different than something that's a transaction within the app that might happen a number of times for a given user since the logon shouldn't be happening very often and you probably won't get too many users doing it concurrently, so it's not a big issue as compared to something that might be happening a lot for many different users.

This really strikes me as something that should be done in a database, whether your letting the database handle the concurrance issues or you do so in your code yourself, but either way, that's really the way I'd be looking.

Frank

From: Mufaddal Khumri <[EMAIL PROTECTED]>
Reply-To: "Tomcat Users List" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Subject: Re: Design question ..
Date: Mon, 21 Jun 2004 14:34:51 -0700

Hi,

Yes , first come first is something that I prefer too. But I will need a singleton java object with a synchronized method to do the transaction. The transaction would involve 1. Check data 2. Register 3. commit data to database. After the method completes i can send them a confirmation.

The downside to this approach is that if lots of users are registering for courses online , they might experience a delay.

On Jun 21, 2004, at 12:47 PM, Peter Lin wrote:

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]

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]


_________________________________________________________________
MSN 9 Dial-up Internet Access fights spam and pop-ups – now 3 months FREE! http://join.msn.click-url.com/go/onm00200361ave/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]



Reply via email to