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:00To: Orion-InterestSubject: 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 

RE: Transaction behaviour

[Ampie Barnard]

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