About Question enthuware.oce-ejbd.v6.2.449 :

[ETS User]

You need to specify that A is a Stateless session bean. For Singleton or Stateful session beans, the bean will not be discarded.

[deadlock_gr]

That was me

[admin]

I don't think that is true as per section 14.3.1, which shows that a session bean is discarded upon a system exception.

[deadlock_gr]

In 14.3.1 there are the following notes:

[C] Discard instance means that the container must not invoke any business methods or container callbacks
on the instance. Discarding does not apply if the bean is a Singleton.

and

[A] Discarding not apply if the bean is a Singleton.

[deadlock_gr]

Another observation (I am not sure about this one): if I have understood correctly, the container destroys the bean that throws the EJBException (the bean B) and not the one that receives it (bean A). If bean A catches and handles the exception instead of re-throwing it, it will not be destroyed.

[deadlock_gr]

I created a test project to test this. Indeed, as you say, bean A is destroyed and not bean B. This seems strange to me, isn't the bean that throws the exception discarded?

[deadlock_gr]

Duh, bean A was discarded because it didn't handle the exception, and rethrew it. And since it threw an EJBException, it was discarded. Now that I handle it, it is not destroyed any more.

So, the question is, why isn't bean B destroyed, since it throws an EJBException.

[admin]

You are right. The bean that throws a system exception out to the container is the one that is discarded.

In this case, the question should specify that no exception handling is done in Bean A. The explanation should be updated accordingly.

As to why Bean B is not discarded, I think it is because it was never invoked by the container. The container throws javax.ejb.EJBTransactionRequiredException to mA() even before invoking mB().

[admin]

In 14.3.1 there are the following notes:

[C] Discard instance means that the container must not invoke any business methods or container callbacks
on the instance. Discarding does not apply if the bean is a Singleton.

and

[A] Discarding not apply if the bean is a Singleton.

I think you are misinterpreting these statements. It is saying that the concept of discarding does not apply to singletons. It does not mean that only singleton beans are not discarded. I believe Table 15 given in this section applies to all session beans.

thank you,
Paul.

[Jofen]

Actually, for the explaination "Therefore, when it calls mB(), it will get a javax.ejb.EJBTransactionRequiredException (a remote client would get javax.transaction.TransactionRequiredException)."

A client would get javax.transaction.TransactionRequiredException only if the client EJB invoked using EJB 2.1 remote view or web service view. Not for EJB 3.1 remote client.

[admin]

Actually, for the explaination "Therefore, when it calls mB(), it will get a javax.ejb.EJBTransactionRequiredException (a remote client would get javax.transaction.TransactionRequiredException)."

A client would get javax.transaction.TransactionRequiredException only if the client EJB invoked using EJB 2.1 remote view or web service view. Not for EJB 3.1 remote client.

Footnote 69 on page 369 of EJB 3.1 specification says, "If the business interface is a remote business interface that extends java.rmi.Remote, the javax.transaction.TransactionRequiredException is thrown to the client instead."

HTH,
Paul.

[himaiMinh]

The explanation says "a remote client would get javax.transaction.TransactionRequiredException".
I guess it should be :

If EJB 2.1 client view is used, the container throws the javax.transaction.TransactionRequireException exception if the client is remote client or the javax.ejb.TransactionRequiredLocalException if the client is local client.

This quote comes from 13.6.2.5 of the spec.

[admin]

The statement in the explanation is correct. Please see my post above. The statement about EJB 2.1 is also correct but not relevant here.
Paul.