This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I'd say that it is a responsibility of a Bean Provider to make sure that the trnx is rolledback when the bean throws sys exception.
When using BMT all transaction management is up to the Bean Provider and the transaction rollback / commit is one of these responsibilities.
Alex (SCJP 1.4, SCBCD 1.3, SCWCD 1.4, SCJD 1.4)
Joined: Apr 09, 2004
but, I think that this is a bad tecnique/practice because I would cach all exception (java.lang.Exception) in my method to rolledback the transaction, and every one knows that this is a very bad practice.
The Container catches a non-application exception; logs it (which can result in alerting the System Administrator); and, unless the bean is a message-driven bean, throws the java.rmi.RemoteException (or subclass thereof) to the client if the client is a remote client, or throws the javax.ejb.EJBException (or subclass thereof) to the client if the client is a local client. The Bean Provider can rely on the Container to perform the following tasks when catching a non-application exception: � The transaction in which the bean method participated will be rolled back. � No other method will be invoked on an instance that threw a non-application exception. This means that the Bean Provider does not have to perform any cleanup actions before throwing a non-application exception. It is the Container that is responsible for the cleanup.
[ July 01, 2004: Message edited by: mini mehta ]
Joined: Apr 11, 2004
Sorry Carlos, my guess was wrong. Mini's post proved that the Bean Provider does not have to rollback the transaction in BMT beans when system exception is thrown. It makes Bean Provider's life just a little bit easier
[ July 01, 2004: Message edited by: Alex Sharkoff ]