RE: Transaction behaviour

[Justin Crosbie]

Title: RE: Transaction behaviour

Hi Ampie,

 

Thats my problem, merely catching the CreateExceptions, etc and rethrowing as EJBExceptions apears not to be sufficient to guarantee a rollback, I must call setRollbackOnly() prior to rethrowing. Is this for definite? I would have expected that explicitly throwing EJBException would automatically cause a rollback because it is considered to be a system-level exception. Does the container analyse the nested Exception to determine if it is sourced as a system exception and not rollback EJBExceptions thrown from application-level Exceptions?

 

I'm sure my confusion is apparent now ;)

 

Thanks,

Justin

-----Original Message-----
From: Ampie Barnard [mailto:[EMAIL PROTECTED]]
Sent: 22 October 2001 07:00
To: Orion-Interest
Subject: 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