my dog learned polymorphism*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Service Activator pattern for seats Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Service Activator pattern for seats" Watch "Service Activator pattern for seats" New topic
Author

Service Activator pattern for seats

Alastair Calderwood
Greenhorn

Joined: Jan 13, 2005
Posts: 22
There is a potential problem booking seats in the prepare itinerary use case. If a customer chooses a seat and takes a long time to pay for it, someone else might quickly choose it and pay for it. As other people have said, it makes sense to lock the seat as soon as it is chosen and keep it locked for a given period, so that it is only available for that session. I agree but my problem is how?

Does it make sense to use Service Activator pattern for this? So, a servlet on the web tier (or in the Swing application) creates a Request message object as soon as the customer chooses a seat and sends it to the ServiceActivator listener on the server, which then activates a lockSeat() method in some order processing session bean. If this method can lock the seat (i.e. that seat is not locked or booked already) it does so and sends the client an acknowledgement. If the client doesn't get this message after a certain time, it just assumes the seat is locked.

Using JMS like this risks showing seats as locked just because of delays in sending messages, but there is also the requirement for fast response times which counts in its favour.

Any opinions?
Deepak Pant
Ranch Hand

Joined: Feb 13, 2004
Posts: 443
Hi,

Let me add my 2 cents:

1. You can lock the seat in an synchronous fashion by writing to a central lock table or by saving unpaid itinerary.

2. To cleanup unpaid intineraries and free up seats you can have a daemon program that will use ServiceActivator to clear seats every 3 days or some pre-configured interval

regards,
Deepak
Alastair Calderwood
Greenhorn

Joined: Jan 13, 2005
Posts: 22
Thanks Deepak. It seems to make more sense to use ServiceActivator (SA) to unlock seats, but I can still see a problem with users who choose a seat but never log in, then just end their session by closing the browser or whatever. These seats would be locked until the next daemon thread was scheduled. Ideally I'd like to use SA to free these seats quickly after the session ends by activating a freeSeat() service.

What do you think?
Deepak Pant
Ranch Hand

Joined: Feb 13, 2004
Posts: 443
Good Point.

This can also be addressed by having a SessionListener (for HTTP) and some kind of Observable class (for SWING) for freeing up seats for users who click on the browser X button.
Alastair Calderwood
Greenhorn

Joined: Jan 13, 2005
Posts: 22
Now I have to choose between optimistic and pessimistic locking. Optimistic is more efficient, but there is the risk that someone can go to pay for a seat thinking that they have it and then find that it has already been taken. Even worse it might be the last seat on the flight, so the flight wouldn't be available.

So it seems that a seat has to be locked as soon as it is chosen (pessimistic). I wanted to use a TO for seat but locks will have to be persisted because if the server crashed, session state would need to be restored. That means I'll need to create a SeatEJB only for holding the lock, but that is very resource-intensive and seems to be overkill.

Anyone any ideas?

Alastair
Dan Huskins
Greenhorn

Joined: Dec 29, 2004
Posts: 15
I like the idea of having 'reserved' seats and 'purchased' seats. For external users, 'reserved' seats are locked for the duration of a the user's HttpSession. When the SessionListener notifies the Web tier of an invalidated session, unpurchased 'reserved' seats are freed. For internal users (Travel Agents), 'reserved' seats last until the agent explicitly removes them, finishes the transation, or closes the application. This can be implemented in a variety of ways (SFSB, an object that holds reserved seats, etc), and do not require a thread to remove them because each action that removes reserved seats requires some sort of GUI action on the client (including closing the app).
Alastair Calderwood
Greenhorn

Joined: Jan 13, 2005
Posts: 22
Dan,

Thanks, I agree that we don't need a thread to clear seats. However this type of seat is not freed *only* by a user action because a session timeout would also require seats to be freed. In fact session timeout can be handled by the SessionListener, just like closing the browser.
Alastair
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Service Activator pattern for seats
 
Similar Threads
no need to lock! ??
lock and unlock
What exactly constitutes "Booking Time"?
The question about LOCK,UNLOCK method
Three questions ablout instructions