How will the EJB container handle exceptions thrown by a business method of a bean with container managed transaction demarcation? [Check all correct answers]
1 If the instance called setRollbackOnly(), the EJB container will rollback the transaction. 2 If the instance did not call setRollbackOnly(), the EJB container will commit the transaction. 3 The EJB container will throw a RemoteException. 4 If the bean represents an entity bean, it will remove the entity from the datasource. 5 If the bean represents a session bean, the bean will be removed from the pool.
Exam soln: 1,2
I thought that if CMT bean throws App Exception , the container will not rollback the ex.But if the setRollbackOnly is already called, the container will roll back the Tx. But if setRollbackOnly is not called, i thought, that client can continue with transaction and tx. is not rollbacked. If client can continue with tx, he may still decide if he wants to commit or rollback the same Tx later....this doesnt mean that container will commit it...???
Am I missing something??? i selected for 1 only and I was wrong according to exam Amol.
An enterprise bean with container-managed transaction demarcation can use the setRollbackOnly() method of its EJBContext object to mark the transaction such that the transaction can never commit. Typically, an enterprise bean marks a transaction for rollback to protect data integrity before throwing an application exception, because APPLICATION exceptions DO NOT automatically cause the Container to rollback the transaction.
However, it does not say that transaction will be commited...
I am guessing to keep the data consistency it is going to commit the transaction.. Not fully convinced though. Let's see if we find something more approriate..
Joined: Jan 04, 2001
I agree with your answer. Answer should be only 1.
Assuming that it is application exception that they are refering to.
Joined: Sep 05, 2003
Hi there Gemini, Thankx for your reply. I think that the objective of container behind not rollbacking the Tx in above context is to allow client to continue as Tx is still valid...but it certainly doesnot commit tx on its own. I think wording of the option is wrong although author(of question) might have right concept in mind. But thank you for your support though. Amol.