File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Service Activator pattern for seats

 
Alastair Calderwood
Greenhorn
Posts: 22
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 446
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 22
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 446
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 22
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 15
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 22
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Don't get me started about those stupid light bulbs.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic