The moose likes EJB and other Java EE Technologies and the fly likes Long Locking Transaction's Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Long Locking Transaction Watch "Long Locking Transaction New topic

Long Locking Transaction's

Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Is it possible to have a
WLS-based transaction that spans
multiple requests in a Web Based application ?
If yes how can this be Iplemented ?
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
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.
Dave Landers
Ranch Hand

Joined: Jul 24, 2002
Posts: 401
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.
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
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 ???
I agree. Here's the link:
subject: Long Locking Transaction's
jQuery in Action, 3rd edition