Page 1 of 1

About Question enthuware.oce-jpad.v6.2.381 :

Posted: Sun Dec 28, 2014 7:25 pm
by bluster
Given that:

In answer #6 the blue explanation states that the call will receive

Code: Select all

 .. a javax.ejb.EJBTransactionRolledbackException ..
The question statement says the invocations are local, thusly:
Assuming all invocations are local<snip>
But the API for EJBTransactionRolledbackException says
This exception is thrown to a remote client<snip>

Perhaps the blue explanation needs to be changed to reflect another exception. Could it be "TransactionRequiredLocalException"? Hope I did not snip anything relevant, though I added the API link below for verification.

API: http://docs.oracle.com/javaee/6/api/jav ... ption.html

Re: About Question enthuware.oce-jpad.v6.2.381 :

Posted: Sun Dec 28, 2014 8:29 pm
by admin
There is a bit of inconsistency in the JavaDoc and EJB 3.1 Specification.

As per Table 15 in Section 14.3.1 (which is meant for session beans) of the specification, the client should receive javax.ejb.EJBTransactionRolledbackException. It further says in NOTE D, "If the business interface is a remote business interface that extends java.rmi.Remote, the javax.transaction.TransactionRolledbackException is thrown to the client, which will receive this exception."

To make matter worse, Table 17, section 14.3.2, "Exceptions from Method Invoked via Session or Entity Bean’s 2.1 Client View or through Web Service Client View" clearly says, "Throw javax.transaction.TransactionRolledbackException to remote client; throw javax.ejb.TransactionRolledbackLocalException to local client."

So it is clear that the Specification authors have made a distinction between EJBTransactionRolledbackException and TransactionRolledbackLocalException and since EJB 2.1 is not really relevant for this exam, we should go with Table 15.

HTH,
Paul.

Re: About Question enthuware.oce-jpad.v6.2.381 :

Posted: Mon Dec 29, 2014 12:01 pm
by bluster
Thanks for the well researched reply. You are unmistakably backed by the better facts, and agreed we should follow that path.

A very minor point - it was Table 4 in 14.3.1 that supplied the data in your 2nd para, not Table 15 (at least in my copy).

Thanks again.

Re: About Question enthuware.oce-jpad.v6.2.381 :

Posted: Thu May 25, 2017 12:46 pm
by johnlong
As I understand bean A is not called in the context of client transaction, because bean A has transaction attribute RequiresNew. Does not that mean that bean method runs in the context of a transaction that the container started immediately before dispatching the business method and therefore javax.ejb.EJBException is thrown instead of javax.ejb.EJBTransactionRolledbackException?

Re: About Question enthuware.oce-jpad.v6.2.381 :

Posted: Thu May 25, 2017 11:09 pm
by admin
Yes, the client will get EJBException but mA will get EJBTransactionRolledbackException because mB executes within the transaction started by mA.

Re: About Question enthuware.oce-jpad.v6.2.381 :

Posted: Fri May 26, 2017 1:08 pm
by johnlong
I understand now. So can we say that EJBTransactionRolledbackException is wrapped into EJBException in mA and then re-thrown to the client?

Re: About Question enthuware.oce-jpad.v6.2.381 :

Posted: Fri May 26, 2017 11:18 pm
by admin
johnlong wrote:I understand now. So can we say that EJBTransactionRolledbackException is wrapped into EJBException in mA and then re-thrown to the client?
No, the specification doesn't mention that EJBTransactionRolledbackException is wrapped into an EJBException in this case but it is certainly possible and makes sense.

Re: About Question enthuware.oce-jpad.v6.2.381 :

Posted: Sun Jun 25, 2017 9:12 pm
by himaiMinh
The 6th option says "The bean A instance will not be discarded."
This may be true if bean A can catch bean B's system exception and handles it.

Re: About Question enthuware.oce-jpad.v6.2.381 :

Posted: Tue Jun 27, 2017 10:20 pm
by admin
System exceptions are not supposed to be caught. Section 14.2.2 of EJB 3.1 spec says:
If the bean method encounters a system exception or error, it should simply propagate the error from the bean method to the container.