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

Moderator: admin

Post Reply
PedroKowalski
Posts: 25
Joined: Thu Aug 04, 2011 10:36 am
Location: Poland
Contact:

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

Post 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!

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

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

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

goetz

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

Post 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.

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

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

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

Alan

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

Post 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.

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

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

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

eugenbesel

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

Post 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?

eugenbesel

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

Post 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???

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

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

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

eugenbesel

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

Post 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)

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

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

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

sanju.ait@gmail.com
Posts: 38
Joined: Fri Aug 16, 2013 11:37 pm
Contact:

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

Post 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?

sanju.ait@gmail.com
Posts: 38
Joined: Fri Aug 16, 2013 11:37 pm
Contact:

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

Post 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?

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

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

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

sanju.ait@gmail.com
Posts: 38
Joined: Fri Aug 16, 2013 11:37 pm
Contact:

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

Post by sanju.ait@gmail.com »

Thanks Paul, if catching system exception would also have discarded instance, I would have been in big trouble, thanks.

johnlong
Posts: 185
Joined: Mon Jun 20, 2016 5:06 pm
Contact:

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

Post 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?

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

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

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

johnlong
Posts: 185
Joined: Mon Jun 20, 2016 5:06 pm
Contact:

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

Post by johnlong »

I see, thank you very much for all your explanations. Passed today with 91%.

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

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

Post by admin »

Congratulations!! Good score!
What did you miss?
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 0 guests