jQuery in Action, 2nd edition*
The moose likes EJB and other Java EE Technologies and the fly likes Stateful Session beans Transaction Boundaries Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Stateful Session beans Transaction Boundaries" Watch "Stateful Session beans Transaction Boundaries" New topic
Author

Stateful Session beans Transaction Boundaries

Graham VMead
Ranch Hand

Joined: Sep 22, 2003
Posts: 154
Hi,

Just taking a look into EJB transactions.

Could someone confirm/deny my basic assumption thank you.

From what I've read in container managed transactions the EJBObject issues a commit (if the method is transactional)when you return from the container.

If this is true, does this mean if you want a transaction boundary to span multiple methods calls to a stateful session bean you are forced to use bean managed transactions or client initiated transactions?

TIA Graham

[ February 20, 2005: Message edited by: Graham VMead ]

[ February 20, 2005: Message edited by: Graham VMead ]
[ February 20, 2005: Message edited by: Graham VMead ]
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
I've always avoided stateful session beans, but I believe they should provide a serializable Handle that you could pass to another session bean method that had transaction demarcation and called the multiple SFSB methods after looking it up using the passed-in Handle.

Of course, that's for an existing SFSB. Any bean could simply create the SFSB, call multiple methods, remove the bean, and finally return from the transactional method. SFSBs and SLSBs aren't any different in this regard.
Dave Clark
Ranch Hand

Joined: Feb 16, 2005
Posts: 52
Hi Graham,

yes - your basic assumptions are correct.

However, in general, you *don't* want to use long running transactions iniitated by clients, since you need to develop a lot of additional logic to account for cleanup of transactions that never complete, and compensating transactions for things that you've gone ahead and commited and need to roll back. Even worse, if you implement your long running transactions as locking the resources that they're working with, you produce resource contention, which will either lock out other transactions or possibly even produce deadlocks.

So you should never use long running transactions for shared resources.

A bettter approach generally is to put a Stateless Session Bean Facade over the business methods that you want to all be executed as a single transaction, and have this SSB demarcate the transaction boundaries (use Required or RequiresNew), and have it pass it's transactional context on to the other Session (and/or Entity beans) it calls. - i.e. using a short-lived transaction. Otherwise execute the multiple steps as separate transactions and allow for sompensating 'undo' transactions.

cheers,

Dave


Dave Clark<br />Senior WebSphere Architect<br /><a href="http://www.versant.com" target="_blank" rel="nofollow">Versant Open Access - JDO2 & EJB3</a>
Graham VMead
Ranch Hand

Joined: Sep 22, 2003
Posts: 154
Thanks for the replies and your time

Graham.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Stateful Session beans Transaction Boundaries