mdb and transactions

[Bob Walker Jr]

Here is a peice of code apearing in ejb2.0 spec page 343:

...
//Now do a transaction that involves the two connections. 
 ut = ejbContext.getUserTransaction(); 

// start the transaction 
ut.begin(); 
// Do database updates and send message. The Container 
// automatically enlists dcon and qsession with the 
// transaction. stmt. executeQuery(...); 
stmt.executeUpdate(...);  
stmt.executeUpdate(...); 
qsender.send( message);  
//commit the transaction 
ut.commit(); 
...

My question is what will happen if the MDB assiciated with the queue does some db update and it decides to rollback the transaction? Since it is asynchronous, I don't think the client program wait till the MDB finishes to execute ut.commit, right?
Another question. Let move qsender.send( message); before the first stmt.executeUpdate. Now assume that
1. qsender.send( message); is executed.
2. first stmt.executeUpdate executes.
3. second stmt.executeUpdate does not go through and the transaction has to rollback.
What will happen to the message that was sent? If the associated MDB has "Required" transaction attribute, and if it does some database updates, what will happen to them?
This is really driving me nuts. Please help.

[Bob Walker Jr]

C'mon guys....nobody??
Kathy, does your book answer this question?

[Steve Agarwal]

I could have tried but I havent reached transaction portion yet.
Steve

[Mikalai Zaikin]

Please,
have a look at EJB 2.0 Specification, page 334-335.
Hope, this will help.

[Bob Walker Jr]

Hi Mikalai,
I did read those pages. Thanks for the pointer. However, I am still confused. Regarding my first part of the post, will the execution of ut.commit(); wait until the message driven bean gets the message and processes it??
THe specification is really very vague about it. It just says that either everything will be committed or every thing will be rolled back. But what does rollback mean in terms of an MDB??
Any insight will be greatly appreciated.

[Mikalai Zaikin]

My understanding is, that EJB container delay JMS transmitting until transaction will be commited, so specification says that developer should not rely on request-response techique of JMS inside one transaction, because request JMS will not be delivered until transaction commited.

[Bob Walker Jr]

Originally posted by Mikalai Zaikin:
My understanding is, that EJB container delay JMS transmitting until transaction will be commited, so specification says that developer should not rely on request-response techique of JMS inside one transaction, because request JMS will not be delivered until transaction commited.

If I understand you correctly, the MDB will not execute until the client trransaction commits. If this is the case, what will happen if the client transaction commits and then MDB executes but fails to updates the database and wants to rollback the transaction?

[Mikalai Zaikin]

[below is only my opinion, it may be wrong]
Once JMS was sent, EJB containes does not care about business
logisc for handling JMS.
For example, onMessage method must not throw any checked exception.
In case of error of DB update during JMS handling, you can throw
exception and it will be JMS container responsibility to requeue
JMS and try again, but for the sender view JMS was sent and it forgets
about the message.

[Kathy Sierra]

Howdy - I'm not sure if I understand the question correctly, but I think Mikalai gave the right answer with the notion that the SEND of the message, within the transaction, is part of the transaction. So if the transaction does not commit, the message sent within that transaction will not be sent. Anything you have within the boundaries of the transaction (the begin() and commit()) is what YOU have decided is to be 'atomic'. So, if you have put the sending of the message as part of the transaction, then you are saying to the Container, "Do not send the message unless the database updates succeed (and anything else in the transaction".
I hope that makes sense and that this was at least part of your question...
cheers,
Kathy

[Bob Walker Jr]

Thanks for your reply, Kathy. Let me try to make the question clearer:
Here is the code:
10. ut = ejbContext.getUserTransaction();
11. ut.begin();
12. stmt.executeUpdate(...);
13. stmt.executeUpdate(...);
14. qsender.send( message);
15. ut.commit();

Now the question is: Suppose the MDB performs some updates in the database upn receiving the message. While doing that something happens and the MDB decides to roll back the work. What will happen to the updates done by the code written above?
I am asking this question because here is what I'm thinking:
The MDB works asynchronously. Therefore, line 14. above will not wait there until the MDB finishes to execute line 15. Is that correct?
Therefore, line 15. (which is a commit() ) will be executed potentially before the MDB gets a chance to even recieve the message, which may as well happen 1 hour later.
I hope it is clear now.
thank a lot for taking time for this and bearing with me.

[Brian Nice]

Are you talking about the so called "Poison" messages, where the MDB gets the message and calls an entity bean which is in a transaction, and a rollback occurs so the MDB tries to resend the message generating an infinite loop? What is the best way to handle something like that?
Thanks
Brian

[Bob Walker Jr]

Originally posted by Brian Nice:
Are you talking about the so called "Poison" messages, where the MDB gets the message and calls an entity bean which is in a transaction, and a rollback occurs so the MDB tries to resend the message generating an infinite loop? What is the best way to handle something like that?
Thanks
Brian

No, I didn't even know about poison messages. But yes, that's an interesting point. I have no idea.
Kathy, does your book answer nagging questions like these?

[Pradeep bhatt]

It is only the sending which is a part of the transaction and not consumption.

[Pradeep bhatt]

http://java.sun.com/products/jms/tutorial/1_3_1-fcs/doc/advanced.html#1026538