Enthuware

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.

This has been updated.

thanks for your feedback!

why isn't the "In any case, the @Timeout method will be invoked again." The right answer also?

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.

What if BMT will be used with MDB? Will the message be redelivered? What about @Timeout method with BMT?

Thanks.

As per section 5.4.12,

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.

Thus, the message delivery is not a part of the transaction and so the message will not be redelivered.

HTH,
Paul.

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

Jofen, yes, if the bean is a CMT then what you said applies.

HTH,
Paul.

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

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:

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.

Therefore, in this case, @Timeout method will not be invoked again.

HTH,
Paul.

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:

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

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

  so in short the container will trigger the timeout.

What I don't understand what/who cancel the timer.

Thanks in advance,
Mihai

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.

Paul, you are right, the specification does not state the "system exception -> redeliver message", I reason this according with the specification 5.4.15.

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.

In short the container acknowledge the message in both cases.

and

5.4.18.

....... If a message-driven bean uses bean-managed transaction demarcation and throws a RuntimeException, the container should not acknowledge the message......

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.

Do I interpret the specification wrong ?


Best Regards,
Mihai

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.

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

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.

Why would the container crash because of system exception?