Scenario: a stateless session bean method (using container managed transactions) calls an update method on a DAO. The DAO calls a stored procedure that fails and a SQLException is thrown in the DAO. The DAO wraps the SQLException as a checked Exception called MyBusinessException. The stateless session bean method catches MyBusinessException, logs it, and returns (without ever calling setRollbackOnly() ).
In this scenario, won't the EJB container try to commit a transaction for a stored procedure that failed?
Yes, the container will commit the transaction. There is no reason for the container not to commit it. How should the container know that an exception has been thrown during execution of the stored procedure. The thing is: The DB will not have anything to commit (internally), so that's not the important part. but why don't you invoke setRollbackOnly(true) as that is the appropriate action to take for the developer if he catches such an exception?
Marco Barenkamp<br />_ _ _ _ _ ________________________ _ _ _ _ _ <br />L M I N T E R N E T S E R V I C E S AG<br /> <br />Head of Software Development<br /> <br /> <br />BEA Certified Enterprise Developer<br />Sun Certified Programmer for the Java2 Platform<br />Sun Certified Web Component Developer for the Java2 Platform<br />Sun Certified Developer for the Java 2 Platform <br />Sun Certified Business Component Developer for the Java 2 Platform <br />Sun Certified Enterprise Architect for the Java 2 Platform Enterprise Edition<br /> <br />LMIS AG