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.
If a bean throws an application exception, the transaction may be continued. Since application exceptions do not have impact on the transaction itself.
This is only true for statefull session beans and entit beans. Stateless and message driven beans must end the transaction before the method ends, so you cannot retry (a retry would mean a new transaction).
Could that be the reason why 1 is fault ?
Joined: May 26, 2005
Answers 1 and 2 are incorrect. It is potentially dangerous retrying to continue with a transaction after receiving an application exception because it is not always possible to determine the state of the enterprise bean. For example, if the container started a transaction just before invoking an enterprise bean with container-managed transaction and the enterprise bean throws an application exception and does not mark the transaction for rollback, the container commits the transaction before re-throwing the application exception to the client. In this scenario, it is not possible for the client to continue with the transaction on receiving the application exception.
Here is an alternative scenario. A transaction begins in a CMT bean (A) which propagates into bean B. If an application exception is thrown in bean B, it will be received by bean A. Let us say that bean A handles the exception. At this point, nothing is committed and it would be quite safe for bean A to take corrective action in the same transaction. (This assumes that the Bean Provider has ensured that the instance of bean B is in a state such that an attempt by bean A to continue and/or commit the transaction does not result in loss of data integrity.)