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

Moderator: admin

Post Reply
ETS User

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

Post by 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
Posts: 54
Joined: Tue Apr 19, 2011 10:32 am
Contact:

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

Post by deadlock_gr »

That was me :-)

admin
Site Admin
Posts: 8920
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

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

Post by 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.
If you like our products and services, please help us by posting your review here.

deadlock_gr
Posts: 54
Joined: Tue Apr 19, 2011 10:32 am
Contact:

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

Post by 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
Posts: 54
Joined: Tue Apr 19, 2011 10:32 am
Contact:

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

Post by 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
Posts: 54
Joined: Tue Apr 19, 2011 10:32 am
Contact:

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

Post by 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
Posts: 54
Joined: Tue Apr 19, 2011 10:32 am
Contact:

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

Post by 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
Site Admin
Posts: 8920
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

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

Post by 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().
If you like our products and services, please help us by posting your review here.

admin
Site Admin
Posts: 8920
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

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

Post by admin »

deadlock_gr wrote: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.
If you like our products and services, please help us by posting your review here.

Jofen
Posts: 9
Joined: Mon Oct 08, 2012 10:09 am
Contact:

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

Post by 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
Site Admin
Posts: 8920
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

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

Post by admin »

Jofen wrote: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.
If you like our products and services, please help us by posting your review here.

himaiMinh
Posts: 358
Joined: Fri Nov 29, 2013 8:26 pm
Contact:

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

Post by 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
Site Admin
Posts: 8920
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

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

Post by 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.
If you like our products and services, please help us by posting your review here.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest