About Question enthuware.oce-ejbd.v6.2.592 :
Moderator: admin
-
- Posts: 25
- Joined: Thu Aug 04, 2011 10:36 am
- Location: Poland
- Contact:
About Question enthuware.oce-ejbd.v6.2.592 :
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!
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!
-
- Site Admin
- Posts: 10102
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.592 :
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.
Re: About Question enthuware.oce-ejbd.v6.2.592 :
According to the spec (14.3.1), the client will receive an EJBException, and that
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.If the client executes in a transaction, the client’s transaction may or may not be marked for rollback.
-
- Site Admin
- Posts: 10102
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.592 :
The details of "may or may not be marked for rollback" are given in Section 14.4. It says,
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 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.
Re: About Question enthuware.oce-ejbd.v6.2.592 :
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.
"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.
-
- Site Admin
- Posts: 10102
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.592 :
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!
"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.
Re: About Question enthuware.oce-ejbd.v6.2.592 :
what is about javax.ejb.EJBTransactionRequiredException?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!
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 :
I tried to implement this behavior.eugenbesel wrote:what is about javax.ejb.EJBTransactionRequiredException?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!
Bean B get an EJBTransactionRequiredException.
should the client get the same exception also or the EJBException contains the EJBTransactionRequiredException?
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???
-
- Site Admin
- Posts: 10102
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.592 :
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.
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.
Re: About Question enthuware.oce-ejbd.v6.2.592 :
Hello Paul,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.
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)
-
- Site Admin
- Posts: 10102
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.592 :
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.
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.
-
- Posts: 38
- Joined: Fri Aug 16, 2013 11:37 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.592 :
If client of Bean A would also have been a statless session bean, its instance would also have been discarded?
-
- Posts: 38
- Joined: Fri Aug 16, 2013 11:37 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.592 :
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?
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?
-
- Site Admin
- Posts: 10102
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.592 :
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.
HTH,
Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 38
- Joined: Fri Aug 16, 2013 11:37 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.592 :
Thanks Paul, if catching system exception would also have discarded instance, I would have been in big trouble, thanks.
-
- Posts: 197
- Joined: Mon Jun 20, 2016 5:06 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.592 :
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?A system exception in a bean's method translates to an EJBException.
-
- Site Admin
- Posts: 10102
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.592 :
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.
-
- Posts: 197
- Joined: Mon Jun 20, 2016 5:06 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.592 :
I see, thank you very much for all your explanations. Passed today with 91%.
-
- Site Admin
- Posts: 10102
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.592 :
Congratulations!! Good score!
What did you miss?
What did you miss?
If you like our products and services, please help us by posting your review here.
Who is online
Users browsing this forum: No registered users and 3 guests