This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of Java Interview Guide and have Anthony DePalma on-line!
See this thread for details.
The moose likes EJB and other Java EE Technologies and the fly likes newBie Question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "newBie Question " Watch "newBie Question " New topic

newBie Question

Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
A Fundamantal Question I have is
Typically , Entity Beans stand for
1) State of one row in the database
2) Listing Behaviour ( A Ship bean will have
a method which list's all it's cabin entity beans)
Now the question i have here is
client 'A' get's a remote referance to a Ship bean calls getCabins(),
and then loops & populates a select drop down in a JSP with the available cabins on a Ship . Assume the list diplays 100 cabins.
Simultaneously another user 'B' books a reservation on the
same ship & consequently there are only 99 free cabins.
What measure's should we take to ensure that Client 'A' is not affected.He may as well select the same cabin as the one selected by the Client 'B' to book a reservation.
How are web application's designed to handle this Scenerio ??
Basically the concept of Transactions is that it isolates the Unit of Data involved in the transaction while the Transaction is taking place .
But here what we are having is a non repeatable read , since if the Client A presses refresh on his browser , he might see an updated 99 cabins only in the -Select- dropdown . Transactions not gonna help here ...?
Dave Landers
Ranch Hand

Joined: Jul 24, 2002
Posts: 401
Everything was just fine until you involved the Web
You are right, Transactions are not going to help you here. This is because HTTP is stateless and so there is no good way to keep the transaction open (nor would you want to, given the time it usually takes your average web user to do something useful).
Usually, the solution involves some sort of optimistic checking. In the Ship/Cabin example, you would be "optimistic" that no one else would reserve a cabin while your user is shopping. But you are not so optimistic as to give the cabin to both persons.
When each user finally confirms their reservation, you have to check that the cabin is still available. If not, you have to present your user with some sort of second option: "Sorry, that cabin is no longer available, would you like this other one instead?...".
You can help the problem by allowing shoppers to place a timed "hold" on the cabin - giving them some time like 5 minutes to give their credit card and confirm their reservation. This at least avoids the "Sorry" page after they've filled out all the difficult forms.
It's all part of the fun of internet commerce.
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Thanx Dave ...
I agree. Here's the link:
subject: newBie Question
It's not a secret anymore!