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.
This is typically done through the use of Stateful Session Beans.
From EJB 2.0 Specification A stateful Session Bean instance may, but is not required to, commit a started transaction before a business method returns. If a transaction has not been completed by the end of a business method, the Container retains the association between the transaction and the instance across multiple client calls until the instance eventually completes the transaction.
In most cases it is undesirable to have transactions span multiple client calls as it tends to negatively affect scalibility.
And if the client browser doesn't come back to make the full series of requests, you lock up a database connection until the session bean times out. A bad idea. Better to collect all the user input (like in HTTPSesssion) and submit it to the database on the final "submit" request.
Joined: Nov 22, 2008
Thanx Chris & Dave but what I wanted to know was if a client A browses some data on a site , intending to update it and then takes a longer period of time by which time the Data in the store is updated by another client B. Now if client A updates the same data , B's changes are lost or we have a BURIED UPDATE . I know we could apply optimistic locking techniques like a Time stamp etc to get over this problem ...but is there a way to lock the data involved in the transaction across HTTP request's ???