This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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 ...?
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.
Joined: Nov 22, 2008
Thanx Dave ...
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com