Enthuware

For this question:
Assuming that all the variables are properly defined and used, what will happen if the MDB associated with the queue Q1 rolls back the transaction but does not throw any exception?

An answer:
Neither the message is sent nor any database changes get committed.

Is incorrect.

Hi,
Why do you think it is incorrect?

thank you,
Paul.

Hi!
I fear that I have misunderstood the question, the question is slightly unclear or that the answer is perhaps not entirely correct.

Motivation as follows:
The method myBeanmethod in MyBean executes and attempts to send a JMS message as well as update the database in one and the same transaction. If both these operations succeed, the transaction is committed, otherwise the transaction is rolled back and the database is not updated and no JMS message is sent.

The MDB listening on the queue receives the message from the queue in a transaction. This transaction is not the same as the transaction in which the message was sent to the queue!
If this transaction is rolled back and the MDB uses container-managed transactions, the JMS message is placed on the queue again, to be re-delivered at some later point in time.
If the MDB rolls back the transaction, any database updates performed in the scope of the transaction will of course also be rolled back.

What I cannot understand is why the question asks about the MDB but refers to code that I understand is located in the EJB MyBean.
Best wishes!

Hi,
The question is a little confusing but seems technically correct. Basically, the sender itself calls ut.rollback() and so the message is never sent and the db updates done by the sender are also rolled back. What ever MDB does is irrelevant because it never gets the message and is never executed.

The explanation should be made more clear.

HTH,
Paul.

I don´t understand why in this question the sending of the msg is on the same transaction, but on enthuware.oce-ejbd.v6.2.578 it´s not. To be honest I'm really confused with this 2 questions :\

In both the questions the sending is indeed a part of the sender's transaction. The difference is that in 2.511, the sender itself calls ut.rollback(), while in 2.578 the sender calls ut.commit().

HTH,
Paul.

Was the session transacted?
connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);

What if session wasn't transacted?

As per section 13.3.5:

Because the container manages the transactional enlistment of JMS sessions on behalf of a bean, the parameters of the createSession(boolean transacted, int acknowledgeMode), createQueueSession(boolean transacted, int acknowledgeMode) and createTopicSession(boolean transacted, int acknowledgeMode) methods are ignored. It is recommended that the Bean Provider specify that a session is transacted, but provide 0 for the value of the acknowledgment mode.

So it wouldn't make any difference because that parameter is ignored.

HTH,
Paul.

I overlooked the last line of code too. This shows how attentive we should be!