Enthuware

I think the first answer may be true. As per 14.3.1, table 15 (at the end). "Bean method runs with an unspecyfied transaction context. This case may happen with the NotSupported, Never, and Supports attributes"..."Client's view receives EJBException. The client receives EJBTransactionRollebBackException but only if the transaction of the caller is present (SUPPORTS). So the answer is wrong for question " A client of a session bean calls a method on the bean and the method throws a system exception. ". The answer will be false if the question would be: "A client of a session bean calls a method on the bean and the method throws a system exception and the caller is in transaction context". Or the first checkbox would have the label: "If the transaction attribute of the method is SUPPORTS and the client is in transaction, the client will get EJBException."

I think the given answer is correct because the option implies that the client will always get an EJBException, which, of course, is not true as noted by the explanation.

"If the bean method runs in the context of a transaction that the container started immediately before dispatching the business method, the client will get EJBException." Yes this is true.

But in explanation : "An example of a situation where this could happen is if Bean1 has transaction attribute of REQUIRED and it calls Bean2, which has transaction attribute of REQUIRES_NEW. In this case, Bean1 will get EJBException and its transaction would not be affected even though Bean2's transaction would be rolled back and its instance discarded."

If Bean1 will get System Exception from Bean2, won't this discard the instance of Bean1?

Getting a system exception and throwing a system exception are two different things. If a bean gets any exception because of any method call that it is has made, it can always catch it and proceed normally.

It is only when a bean method throws a system exception outside the bean (i.e. to the container), it is destroyed.

HTH,
Paul.

Throwing system exception is the culprit of instance discarding and not catching system exception.
Thanks a lot Paul.

I think that:
The last option is true too.
If the bean method runs in the context of a transaction that the container started immediately before dispatching the business method, the client will get EJBTransactionRolledbackException.
Explanation:
An example of a situation where this could happen is if Bean1 has transaction attribute of REQUIRED and it calls Bean2, which has transaction attribute of REQUIRED. In this case, Bean1 will get EJBTransactionRolledbackException .

Because as the right answer:
If the bean method runs in the context of a transaction that the container started immediately before dispatching the business method, the client will get EJBException.
Explanation:
An example of a situation where this could happen is if Bean1 has transaction attribute of REQUIRED and it calls Bean2, which has transaction attribute of REQUIRES_NEW. In this case, Bean1 will get EJBException and its transaction would not be affected even though Bean2's transaction would be rolled back and its instance discarded.

I am sorry but I am not sure what you mean. Option 5 is not correct because in that case the client will get EJBException (not EJBTransactionRolledbackException ) as explained in option 3.

aposoft wrote:I think that:
The last option is true too.
If the bean method runs in the context of a transaction that the container started immediately before dispatching the business method, the client will get EJBTransactionRolledbackException.
Explanation:
An example of a situation where this could happen is if Bean1 has transaction attribute of REQUIRED and it calls Bean2, which has transaction attribute of REQUIRED. In this case, Bean1 will get EJBTransactionRolledbackException .

Because as the right answer:
If the bean method runs in the context of a transaction that the container started immediately before dispatching the business method, the client will get EJBException.
Explanation:
An example of a situation where this could happen is if Bean1 has transaction attribute of REQUIRED and it calls Bean2, which has transaction attribute of REQUIRES_NEW. In this case, Bean1 will get EJBException and its transaction would not be affected even though Bean2's transaction would be rolled back and its instance discarded.

I'm sorry, I was confusing the client's transaction with the transaction started by the container before dispatching the business method.