Enthuware

Hi!
This is another example of a question related to MDB and transactions that is quite unclear.
As far as I know, transactions does not propagate over JMS:
The sending of a JMS message takes place in one transaction, the receiving of the same message in another transaction.
Thus there is no correct answer alternative in this question.

As far as I know, transactions does not propagate over JMS:
The sending of a JMS message takes place in one transaction, the receiving of the same message in another transaction.

Exactly, so the sending side is not affected at all.

The correct answer is option 1, "Changes made by the bean code at line 23 will be committed.". This is explained in detail in the given explanation as well.

what is the difference between this question and enthuware.oce-ejbd.v6.2.511. I am confused

In 2.578, it is given that the MDB associated with the queue is a BMT bean, while in 2.511, this information is not given, so it could be either BMT or CMT. The options are different as well.

HTH,
Paul.

I some questions regarding the explanation given in this question:

1 CMT MDB: In case of a rollback (without system exception), is the msg redelivered or not?
2 CMT MDB: In case of a rollback, with system error, the msg is redelivered, right?
3 BMT MDB: In case of a rollback (without system exception), no msg redelived, right?
4 BMT MDB: In case of a rollback, with system error, what happens?

I´m a bit confused because of this:

...and the message will be redelivered later because as per Section 5.4.18, If a message-driven bean uses bean-managed transaction demarcation and throws a RuntimeException, the container should not acknowledge the message.

and

Note that, in case of a CMT MDB (with transaction attribute of REQUIRED), the container starts a transaction before dequeuing the message. So, if the bean throws a system exception, or calls setRollbackOnly(), the message will be redelivered to another instance of the MDB but in case of BMT, the message is not redelivered because message dequeuing is not a part of the transaction

Thanks in advance!

I'm having my exam in 2 days and this is the only questions that I'm still a bit confused, so can you please help? Thanks!

>1. CMT MDB: In case of a rollback (without system exception), is the msg redelivered or not?
>2 CMT MDB: In case of a rollback, with system error, the msg is redelivered, right?

As per section 13.6.3.2, "If the onMessage method does not successfully complete or the transaction is rolled back, message redelivery semantics apply."

So, in both of the above cases the message is redelivered.


>3 BMT MDB: In case of a rollback (without system exception), no msg redelived, right?
>4 BMT MDB: In case of a rollback, with system error, what happens?

In case of a BMT, as per section 5.4.15:

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. If bean-managed transaction demarcation is used, the Bean Provider can indicate whether JMS AUTO_ACKNOWLEDGE semantics or DUPS_OK_ACKNOWLEDGE semantics should apply by using the activationConfig element of the MessageDriven annotation or by using the activation-config-property deployment descriptor element. The property name used to specify the acknowledgment mode is acknowledgeMode. If the acknowledgeMode property is not specified, JMS AUTO_ACKNOWLEDGE semantics are assumed.

and as per Section 5.4.18

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

This means, there are a total of four possibilities:
P1: MDB calls rollback but no system exception + AUTO_ACKNOWLEDGE :
Message should NOT be redelivered.

P2: MDB throws system exception + AUTO_ACKNOWLEDGE :
Message should be redelivered.

P3: MDB calls rollback but no system exception + DUPS_OK_ACKNOWLEDGE :
Message may be redelivered.

P4: MDB throws system exception + DUPS_OK_ACKNOWLEDGE :
Message should be redelivered.

HTH,
Paul.

Hi Paul,

Thanks for the answer. Now I understand! =)

For option 3, I think the message has already been sent to the queue on line 24.
But what I believe is that the MDB receives the message from the queue and executes onMessage in a transaction. But the transaction is rolled back.

I think it is still right to say the message is sent to the queue.
Correct me if I am wrong.

That is why the option is wrong.

Hi, for option 3

,
Changes made by the bean code at line 23 will be committed, but the message sent at line 24 will not be sent.

Based on the explanation using the term "redeliver",
Should it be clearer to change this phrase into:

.... the message sent at line 24 will not be re-sent

?

No, it is fine as it is because it is a wrong option.

Hi, admin,
Maybe I have been misunderstanding the question.
What I am interpreting from the scenario is:
1. the message at line 24 is put in the queue.
2. the MDB receives it.
3. the MDB's onMessage rollback the transaction after it receives the message from line 24.
4. the container won't redeliver the message.

Correct me if my interpretation of the question is wrong.

himaiMinh wrote:Hi, admin,
Maybe I have been misunderstanding the question.
What I am interpreting from the scenario is:
1. the message at line 24 is put in the queue.
2. the MDB receives it.
3. the MDB's onMessage rollback the transaction after it receives the message from line 24.
4. the container won't redeliver the message.

Correct me if my interpretation of the question is wrong.

What you said above is correct.
Paul.

Sorry for my English I only Spanish

In the Explanation to te question you say

As per Section 5.4.15, 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. If a MDB does not throw any exception while processing the message (Note: It can only throw RuntimeExceptions such as EJBException from onMessage()), ....

But in point 5.4.18 of the specification says

....
Message-driven beans should not, in general, throw RuntimeExceptions.

....
The message listener methods of some messaging types may throw application exceptions. An applica-
tion exception is propagated by the container to the resource adapter.

who is right

Both are correct. It should not. But it can (it is possible to throw it). You can also annotate a runtime exception with @ApplicationException.