Page 1 of 1

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

Posted: Wed Aug 10, 2011 9:58 am
by PedroKowalski
Hello. I've got a question.

I understand that Bean B is not affected. Bean A receives a SystemException, but it doesn't run in any transaction, so it won't rollback anything but only it's instance will be discarded.

One thing that bothers me, is that if the Bean A doesn't catch the SystemException (runtimeException), won't it be propagated further (re-thrown) to the actual client? Won't it be treated like a SystemException which occured in client transaction? Therefore shouldn't the client transaction be rolled back?

Thanks in advance!

Cheers!

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

Posted: Sun Aug 14, 2011 8:59 am
by admin
No, it will not affect because client's transaction was suspended during the call. If the call throws a system exception, the client still has an option to catch it and not roll back its transaction. Had the same transaction been propagated to BeanA, the transaction would have been marked by roll back by the container and it that case the client wouldn't have a choice.

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

Posted: Mon Jan 16, 2012 5:22 am
by goetz
According to the spec (14.3.1), the client will receive an EJBException, and that
If the client executes in a transaction, the client’s transaction may or may not be marked for rollback.
So I think the answer should be "None of the above", because the client's suspended transaction is not guaranteed not to rollback in this case.

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

Posted: Mon Jan 16, 2012 8:34 am
by admin
The details of "may or may not be marked for rollback" are given in Section 14.4. It says,
If the client executes in the context of a transaction, the client’s transaction may, or may not, have been marked for rollback by the communication subsystem or target bean’s container.
For example, the transaction would be marked for rollback if the underlying transaction service or the target bean’s container doubted the integrity of the data because the business method may have been partially completed. Partial completion could happen, for example, when the target bean’s method returned with a RuntimeException exception, or if the remote server crashed in the middle of executing the business method.
The transaction may not necessarily be marked for rollback. This might occur, for example, when the communication subsystem on the client-side has not been able to send the request to the server.

In the situation given in the question, the client's transaction was suspend, so it cannot be affected by anything that happens in Bean A. Therefore, the client's transaction will not be marked for rollback.

HTH,
Paul.

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

Posted: Fri Mar 09, 2012 9:58 am
by Alan
The explanation is not very clear:
"A system exception in a bean's method translates to an EJBException for a local client and a RemoteException for a remote client."

But according to enthuware.oce-ejbd.v6.2.408 the client always receives EJBException despite the fact that is is Remote client.

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

Posted: Sat Mar 10, 2012 7:47 am
by admin
This is correct but only if the remote business interface extends java.rmi.Remote. So the explanation to 2.592 should be updated to :
"A system exception in a bean's method translates to an EJBException.However, if the business interface is a remote business interface that extends java.rmi.Remote, the java.rmi.RemoteException is thrown to the remote client."

thank you for your feedback!

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

Posted: Wed Nov 14, 2012 10:26 am
by eugenbesel
admin wrote:This is correct but only if the remote business interface extends java.rmi.Remote. So the explanation to 2.592 should be updated to :
"A system exception in a bean's method translates to an EJBException.However, if the business interface is a remote business interface that extends java.rmi.Remote, the java.rmi.RemoteException is thrown to the remote client."

thank you for your feedback!
what is about javax.ejb.EJBTransactionRequiredException?
Bean B get an EJBTransactionRequiredException.
should the client get the same exception also or the EJBException contains the EJBTransactionRequiredException?

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

Posted: Wed Nov 14, 2012 12:08 pm
by eugenbesel
eugenbesel wrote:
admin wrote:This is correct but only if the remote business interface extends java.rmi.Remote. So the explanation to 2.592 should be updated to :
"A system exception in a bean's method translates to an EJBException.However, if the business interface is a remote business interface that extends java.rmi.Remote, the java.rmi.RemoteException is thrown to the remote client."

thank you for your feedback!
what is about javax.ejb.EJBTransactionRequiredException?
Bean B get an EJBTransactionRequiredException.
should the client get the same exception also or the EJBException contains the EJBTransactionRequiredException?
I tried to implement this behavior.
I created three stateless EJB's
One with TransactionAttribute = REQUIRED
One with TransactionAttribute = NOT_SUPPORTED
And one with TransactionAttribute = MANDATORY

The EJB with Required attribute get an javax.ejb.EJBTransactionRequiredException and not EJBException as described in the explanation.

have I done something wrong or is the answer "None of the above." correct for this question???

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

Posted: Sun Nov 18, 2012 10:13 am
by admin
As per the given situation the bean A with Tx of NON_SUPPORTED should get javax.ejb.EJBTransactionRequiredException.

The client (which does execute in a transaction context) that calls bean A should not get EJBTransactionRequiredException because it already has a transaction.

You might be seeing a wrapped/root cause exception of the EJBException. Can you please confirm if you are running the exact same situation described in the question? If so, that doesn't seem to be compliant to the specification.

HTH,
Paul.

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

Posted: Tue Nov 20, 2012 3:29 am
by eugenbesel
admin wrote:As per the given situation the bean A with Tx of NON_SUPPORTED should get javax.ejb.EJBTransactionRequiredException.

The client (which does execute in a transaction context) that calls bean A should not get EJBTransactionRequiredException because it already has a transaction.

You might be seeing a wrapped/root cause exception of the EJBException. Can you please confirm if you are running the exact same situation described in the question? If so, that doesn't seem to be compliant to the specification.

HTH,
Paul.
Hello Paul,

my code looks like this:

@Singleton
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class RequestedClass{
private BeanA beanA;
public String testMethod() {
beanA.testBeanA();
return "foo";
}
}

@Stateless
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public class BeanA {

@EJB
BeanB beanB;

public void testBeanA() {
beanB.testBeanB();
}

}

@Stateless
@TransactionAttribute(TransactionAttributeType.MANDATORY)
public class BeanB {

public void testBeanB() {

}

}

the first class "RequestedClass" is executed from a servlet.

here is the exception which is thrown while running my test code (I can not see any EJBException):

WARNUNG: EJB5184:A system exception occurred during an invocation on EJB BeanB, method: public void de.scja.ejb.BeanB.testBeanB()
WARNUNG: javax.ejb.TransactionRequiredLocalException
at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4586)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1914)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy144.testBeanB(Unknown Source)
at de.scja.ejb.__EJB31_Generated__BeanB__Intf____Bean__.testBeanB(Unknown Source)
at de.scja.ejb.BeanA.testBeanA(BeanA.java:16)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

...
Caused by: javax.ejb.TransactionRequiredLocalException
at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4586)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1914)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
... 82 more

WARNUNG: EJB5184:A system exception occurred during an invocation on EJB InterceptedEJB, method: public java.lang.String de.scja.ejb.InterceptedEJB.testMethod()
WARNUNG: javax.ejb.EJBTransactionRequiredException
at com.sun.ejb.containers.BaseContainer.mapLocal3xException(BaseContainer.java:2317)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2096)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1994)

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

Posted: Tue Nov 20, 2012 7:30 am
by admin
Hi,
Table 15 of EJB 3.1 specification clearly says that in case of any system exception, the container must throw EJBException to client. So I think the implementation is not compliant. It does show root cause (i.e. the cause by section) as EJBTransactionRequiredException, as I suspected.

May be since EJBTransactionRequiredException extends EJBException, it can be argued that it is complaint. But the wordings of the specification are very clear. It says, "Throw EJBException".

HTH,
Paul.

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

Posted: Fri Aug 30, 2013 1:39 am
by sanju.ait@gmail.com
If client of Bean A would also have been a statless session bean, its instance would also have been discarded?

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

Posted: Sun Sep 01, 2013 11:32 am
by sanju.ait@gmail.com
Bean instance is discarded when system exception is thrown from bean.

Here bean A could have caught system exception from bean B and handled properly, I agree if bean A would have thrown system exception from bean B as it is to the container, than bean A instance will also get discarded, but it is no where mentioned that bean A didn't handle any system exception it got from bean B. So how bean A instance got discarded?

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

Posted: Sun Sep 01, 2013 11:59 am
by admin
You are right, it doesn't say whether A handles the exception or not. That is why "Bean A will be discarded is not in the options" either. The explanation is just talking about a hypothetical situation where the exception is not caught because normally such system exception are not meant to be caught.

HTH,
Paul.

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

Posted: Sun Sep 01, 2013 12:08 pm
by sanju.ait@gmail.com
Thanks Paul, if catching system exception would also have discarded instance, I would have been in big trouble, thanks.

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

Posted: Mon Jun 12, 2017 1:55 pm
by johnlong
A system exception in a bean's method translates to an EJBException.
Does this translation happen in Bean A's method? Bean A's method receives javax.ejb.EJBTransactionRolledbackException, wraps it to EJBException and throws it further down to the call chain?

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

Posted: Mon Jun 12, 2017 9:27 pm
by admin
No, the translation is done by the container. Bean A's method will simply propagate whatever exception it receives up to the container (if it is not caught by the bean A's method). The container will then decide what exception should actually be thrown to the client.

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

Posted: Tue Jun 13, 2017 2:21 pm
by johnlong
I see, thank you very much for all your explanations. Passed today with 91%.

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

Posted: Wed Jun 14, 2017 9:51 pm
by admin
Congratulations!! Good score!
What did you miss?