Stateful Session beans Transaction Boundaries

[Graham VMead]

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]

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]

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

[Graham VMead]

Thanks for the replies and your time

Graham.