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.
have a look at EJB 2.0 Specification, page 334-335.
Hope, this will help.
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.
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?
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.
I hope that makes sense and that this was at least part of your question...
Here is the code:
10. ut = ejbContext.getUserTransaction();
14. qsender.send( message);
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.
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?
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?