About Question enthuware.oce-ejbd.v6.2.541 :
Moderator: admin
About Question enthuware.oce-ejbd.v6.2.541 :
there is in the possible answer: "If the bean uses CMT and if the @Timeout method has started any new transaction, the container will discard the bean instance."
I will refactor it to: "If the bean uses CMT and if the code in @Timeout method has started any new transaction, the container will discard the bean instance."
In current form the sentence in my opinion does not exclude the possibility to start a new transaction by annotation or deployment descriptor and this is required if the second answer should be marked as invalid.
I will refactor it to: "If the bean uses CMT and if the code in @Timeout method has started any new transaction, the container will discard the bean instance."
In current form the sentence in my opinion does not exclude the possibility to start a new transaction by annotation or deployment descriptor and this is required if the second answer should be marked as invalid.
-
- Site Admin
- Posts: 10065
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.541 :
This has been updated.
thanks for your feedback!
thanks 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.541 :
why isn't the "In any case, the @Timeout method will be invoked again." The right answer also?
-
- Site Admin
- Posts: 10065
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.541 :
It is not correct because the execution of timeout method is not part of the message delivery and so the container just discards the bean instance. The message will not be redelivered and the time will not be created again.
HTH,
Paul.
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.541 :
What if BMT will be used with MDB? Will the message be redelivered? What about @Timeout method with BMT?
Thanks.
Thanks.
-
- Site Admin
- Posts: 10065
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.541 :
As per section 5.4.12,
HTH,
Paul.
Thus, the message delivery is not a part of the transaction and so the message will not be redelivered.When a message-driven bean using bean-managed transaction demarcation uses the javax.transaction.UserTransaction interface to demarcate transactions, the message receipt that causes the bean to be invoked is not part of the transaction. If the message receipt is to be part of the transaction, container-managed transaction demarcation with the REQUIRED transaction attribute must be used.
HTH,
Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 9
- Joined: Mon Oct 08, 2012 10:09 am
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.541 :
If the MDB has no transaction attributes specified, it default to be required. So the timeout method will be invoked in a transaction, and if the bean throws an EJBException from its @Timeout method, the @Timeout method will be invoked again on a different instance as explained in v6.2.427. Am I right?
Thanks
Thanks
-
- Site Admin
- Posts: 10065
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.541 :
Jofen, yes, if the bean is a CMT then what you said applies.
HTH,
Paul.
HTH,
Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 22
- Joined: Thu Jul 25, 2013 3:39 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.541 :
Hi guys,
Here are my thoughts.
1. The MDB creates the timer for it self via its onMessage method.
2. The Timeout method throws an System Exception and the MDB instance together with the timer get discarded.
3. The container need to try at least once to trigger the timeout method so from this perspective both answers:
"Regardless of whether the @Timeout method starts a transaction or not, the container will invoke the @Timeout method again."
and
"In any case, the @Timeout method will be invoked again"
seams to be correct.
Am I missing something here ?
Thanks in advance,
Mihai
Here are my thoughts.
1. The MDB creates the timer for it self via its onMessage method.
2. The Timeout method throws an System Exception and the MDB instance together with the timer get discarded.
3. The container need to try at least once to trigger the timeout method so from this perspective both answers:
"Regardless of whether the @Timeout method starts a transaction or not, the container will invoke the @Timeout method again."
and
"In any case, the @Timeout method will be invoked again"
seams to be correct.
Am I missing something here ?
Thanks in advance,
Mihai
-
- Site Admin
- Posts: 10065
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.541 :
This will not happen for a BMT because in case of a BMT, a message is not redelivered in case of any exception. As per section 5.4.12:
HTH,
Paul.
Therefore, in this case, @Timeout method will not be invoked again.When a message-driven bean using bean-managed transaction demarcation uses the javax.transaction.UserTransaction interface to demarcate transactions, the message receipt that causes the bean to be invoked is not part of the transaction. If the message receipt is to be part of the transaction, container-managed transaction demarcation with the REQUIRED transaction attribute must be used.
HTH,
Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 22
- Joined: Thu Jul 25, 2013 3:39 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.541 :
Dear Paul,
I agree with you, for MDB with BTM the message recipient is not part of the transaction. For this in order to get a message redelivery a system exception is required.
What I don't understand is the (system) exception occurs in the timeout method, so from this point of view the container does:
Thanks in advance,
Mihai
I agree with you, for MDB with BTM the message recipient is not part of the transaction. For this in order to get a message redelivery a system exception is required.
What I don't understand is the (system) exception occurs in the timeout method, so from this point of view the container does:
- 1. Log the exception
2. Discard the bean instance
3. Out timer is a multi-fire (call multiple times) timer, it was created in the onMessage method without any exception (that may roll back the timer creation) so, the involved MDB is still register like timer.
4. According with the specification 18.4.3.
so in short the container will trigger the timeout..........The container must retry the timeout after the transaction rollback.
Timers are persistent objects (unless explicitly created as non-persistent timers). In the event of a container crash or container shutdown, any single-event persistent timers that have expired during the intervening time before container restart must cause the corresponding timeout callback method to be invoked upon restart. Any interval persistent timers or schedule based persistent timers that have expired during the intervening time.
Thanks in advance,
Mihai
-
- Site Admin
- Posts: 10065
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.541 :
Could you please point me where in the spec it says that in order to get a message redelivery a system exception is required? I am unable to find anything on this in the specification.
thank you,
Paul.
thank you,
Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 22
- Joined: Thu Jul 25, 2013 3:39 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.541 :
Paul, you are right, the specification does not state the "system exception -> redeliver message", I reason this according with the specification 5.4.15.
and
5.4.18.
Do I interpret the specification wrong ?
Best Regards,
Mihai
In short the container acknowledge the message in both cases.JMS message-driven beans should not attempt to use the JMS API for message acknowledgment. Message acknowledgment is automatically handled by the container. If the message-driven bean uses container-managed transaction demarcation, message acknowledgment is handled automatically as a part of the transaction commit. If bean-managed transaction demarcation is used, the message receipt cannot be part of the bean-managed transaction, and, in this case, the receipt is acknowledged by the container.
and
5.4.18.
So if the onMethod(interceptors) ends normal (no runtime exception are throw) the message is acknowledge and the message redistribution policy does not take place but if a RTE occurs then the message is not acknowledged and it may be re-deployed........ If a message-driven bean uses bean-managed transaction demarcation and throws a RuntimeException, the container should not acknowledge the message......
Do I interpret the specification wrong ?
Best Regards,
Mihai
-
- Site Admin
- Posts: 10065
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.541 :
I think I see what you mean. The timeout method and the bean's onMessage are decoupled. So any exception from the timeout method has no bearing on the message acknowledgement or redelivery of the message, which is dependent upon the bean's onMessage method. The message is already acknowledge after the onMessage complete successfully. So there is no question of redelivery here.
Now, as per section 18.2.8, "A timeout callback method on a bean with container-managed transactions has transaction attribute REQUIRED or REQUIRES_NEW. If the container-managed transaction is rolled back, the container retries the timeout."
Further, as per section 14.3.6, table 23, if the time out method of a CMT bean throws a system exception, the container rolls back the container-started transaction.
Thus, in case of CMT, the timeout method will be invoked again. This is clear.
However, it is not clear from the specification what happens upon a system exception from a timeout method if the bean uses BMT. In absence of any clear statement, it cannot be said that the timeout method will be invoked again for a BMT bean.
HTH,
Paul.
Now, as per section 18.2.8, "A timeout callback method on a bean with container-managed transactions has transaction attribute REQUIRED or REQUIRES_NEW. If the container-managed transaction is rolled back, the container retries the timeout."
Further, as per section 14.3.6, table 23, if the time out method of a CMT bean throws a system exception, the container rolls back the container-started transaction.
Thus, in case of CMT, the timeout method will be invoked again. This is clear.
However, it is not clear from the specification what happens upon a system exception from a timeout method if the bean uses BMT. In absence of any clear statement, it cannot be said that the timeout method will be invoked again for a BMT bean.
HTH,
Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 22
- Joined: Thu Jul 25, 2013 3:39 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.541 :
Dear Paul,
This is exactly that I mean, the onMessage and the timer method are separated.
I also agree with you that the specification are much to vague about BTM and timeout. I can reason that it may be similar with the CTM but this can be only a speculation.
Under this circumstances I propose to remove this question from the test - or to change it from BTM to CTM.
Best Regards,
Mihai
This is exactly that I mean, the onMessage and the timer method are separated.
I also agree with you that the specification are much to vague about BTM and timeout. I can reason that it may be similar with the CTM but this can be only a speculation.
Under this circumstances I propose to remove this question from the test - or to change it from BTM to CTM.
Best Regards,
Mihai
-
- Posts: 358
- Joined: Fri Nov 29, 2013 8:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.541 :
My concern is about system exception thrown from a timer.
If the system exception is not handled by the client, the container will crash.
And if the timer is persistent , the timer will be invoked when the container restarts.
So, option 4 may be correct if the timer is persistent.
If the system exception is not handled by the client, the container will crash.
And if the timer is persistent , the timer will be invoked when the container restarts.
So, option 4 may be correct if the timer is persistent.
-
- Site Admin
- Posts: 10065
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.541 :
Why would the container crash because of system exception?
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 81 guests