Title: RE: Transaction behaviour

Orion's implementation is quite correct in returning a method result and not throwing any exceptions, in spite of your invocation of setRollbackOnly. Personally, I only call setRollBackOnly before (re-)throwing an application exception that should definitely cause a rollback. Rolling back the transaction without throwing any exceptions will just confuse the users of my ejb's.  It is probably better to just wrap such an application exception in an EJBException and let the container roll the tx back.

Remember that CreateException, RemoveException and FinderException are considered to be application exceptions. If you propagate these exceptions but still want to roll the tx back, you have to catch them, call setRollbackOnly() and then rethrow them. Subclasses of Error, RuntimeException (EJBException) and RemoteException are considered to be system exceptions and will automatically cause a tx rollback.

-----Original Message-----
From: Justin Crosbie [mailto:[EMAIL PROTECTED]]
Sent: 19 October 2001 05:34
To: Orion-Interest
Subject: Transaction behaviour


Hi all,

We have implemented a session facade architecture, with session beans
calling multiple entity beans. We have configured the <trans-attribute> as
"Required" for everything, as normal.

What is the exact criteria for a session method to rollback? Is it that it
must be a system initiated exception, or else the application must call
setRollBackOnly()?

Its just that calling this method causes a rollback, but the the container
does not come up with the "Session was rolled back" exception, so I'm a bit
worried about it.

I know this has been addressed before on this list, so I apologise for going
over old stuff, but I've noticed that some applications call the
setRollbackOnly method and others don't. Is it just that those ones don't
care if a rollback occurs?

Specificaly, we have a stateless session bean that we invoke through a
statefull one (that a servlet creates and invokes). The stateless bean
always tries to create the entity beans. We would like it such that if
either fails to create, the method does a rollback - all or nothing. Does
this mean that we must call setRollbackOnly() ?

Thanks for any help on this.
Justin

Reply via email to