| Author |
Message
|
| KaiW |
 Posted: Mon Dec 18, 2006 5:48 am Post subject: [solved] XA transacted message sent but not received |
 |
|
Newbie
Joined: 18 Dec 2006
Posts: 5
|
Hello everybody,
I am trying to send a Message from Bea Weblogic AppServer 8.1 to WebSphere MQ 6.0 via JMS using the Extended Transactional Client .
The Sender in Bea is a Session EJB (with container managed tx) with the following code:
| Code: |
connection = queueFactory.createQueueConnection();
session = connection.createQueueSession(true, 0);
sender = session.createSender(queue);
TestMessage msg = session.createTextMessage("test");
sender.send(msg);
log.info("Message sent.");
|
The Sender sends the message without complaint, however I don't receive any message in the MQ Queue.
If I create the QueueSession with
createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
I receive the message.
I am using a xaqcf and I connect via a Foreign JMS Server in Bea.
My guess is that the transaction is not commited in MQ but I wonder how it could be sent without a complaint then.
Am I missing something? Any ideas?
Kai
Last edited by KaiW on Tue Dec 19, 2006 1:41 am; edited 1 time in total |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Dec 18, 2006 5:55 am Post subject: Re: XA transacted message sent but not received (Bea -> M |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| KaiW wrote: |
My guess is that the transaction is not commited in MQ but I wonder how it could be sent without a complaint then.
|
If the put is successful (i.e. message reaches the queue) within a logical unit of work then no error will be generated. In theory a number of such puts could be done within a single UOW in the same way a number of database updates could be done. All would work without complaint, but if the transaction is subsequently rolled back, all the updates will disappear.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| KaiW |
| Posted: Mon Dec 18, 2006 7:15 am Post subject: |
|
|
Newbie
Joined: 18 Dec 2006
Posts: 5
|
Then the question would be, when is the UOW commited and how do I see what the result of the commit is?
Is there a way to see in the logs what exactly is happening? Or rather, how do I look at the logs as they seem to be binary.
Kai |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 18, 2006 7:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| KaiW wrote: |
Then the question would be, when is the UOW commited and how do I see what the result of the commit is?
Is there a way to see in the logs what exactly is happening? Or rather, how do I look at the logs as they seem to be binary.
Kai |
The UOW will be committed when something (typically your application) signals commit using whatever method is appropriate (possibly but not exclusively an MQCMIT). Or it will be rolled back if something issues a rollback (again typically your applicaiton in the event of a processing error). AUTO_ACKNOWLEDGE simply means JMS is doing this for you at whatever point it determines the UOW is complete.
The queue manager logs are proprietory format binary and contain no information of use to you. Puting a read lock on them (by trying to read them) can make the queue manager cross and should be avoided.
The human readable logs are in the errors folder associated with the queue manager.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| KaiW |
| Posted: Mon Dec 18, 2006 7:48 am Post subject: |
|
|
Newbie
Joined: 18 Dec 2006
Posts: 5
|
Thanks Vitor,
you have been very helpful so far.
Hm, so I have to find out, what stops Bea from committing the UOW.
What I am trying to achieve is an exactly once delivery without any messages getting lost on their way to MQ. Would AUTO_ACKNOWLEDGE perhaps suffice for this?
Still I can see neither in the MQ nor in the Bea logs anything about a rollback 
Kai |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 18, 2006 7:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| KaiW wrote: |
Hm, so I have to find out, what stops Bea from committing the UOW.
|
Not setting AUTO_ACKNOWLEDGE. By not setting that you're taking manual control of the transaction and hence if you don't issue a commit, no commit is issued.
| KaiW wrote: |
What I am trying to achieve is an exactly once delivery without any messages getting lost on their way to MQ. Would AUTO_ACKNOWLEDGE perhaps suffice for this?
|
Transactional control is nothing to do with "exactly once" delievery. MQ guarantees that out of the box irrespective of the transactional control in use. By using the ETC and UOW I would have expected you to be trying to coordinate the messages with database updates or other external resources. Even if in your scenario if you specificed a message to be outside the UOW (MQPMO_NO_SYNCPOINT) it would still only be delivered once. Just before the ones in the UOW, delivered only on commit.
So what you're achieving is "exactly once or not at all".
| KaiW wrote: |
Still I can see neither in the MQ nor in the Bea logs anything about a rollback
|
You wouldn't - a rollback is not a software error. It's the application asking for something. Rollbacks are not logged any more than commits are.
I don't think UOW & ETC does what you think it does. Check out some of the documentation.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| KaiW |
| Posted: Mon Dec 18, 2006 8:15 am Post subject: |
|
|
Newbie
Joined: 18 Dec 2006
Posts: 5
|
Ok, I think I am seeing clearer now.
| Quote: |
| Transactional control is nothing to do with "exactly once" delievery. MQ guarantees that out of the box irrespective of the transactional control in use. |
This was the info I was missing. I do use the global transaction on the way back when updating the database from a mdb. I just was not sure how to assure the exactly once delivery.
| Quote: |
By not setting that you're taking manual control of the transaction and hence if you don't issue a commit, no commit is issued.
|
But shouldn't the commit be issued automatically by the container if I use a container managed tx? The QueueConnectionFactory should be the only resource participating in the tx.
Lots of thanks!
Kai |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 18, 2006 8:35 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| KaiW wrote: |
But shouldn't the commit be issued automatically by the container if I use a container managed tx? The QueueConnectionFactory should be the only resource participating in the tx.
|
I think that by not setting AUTO.ACKNOWLEDGE you're moving control away from the QCF (they'll be a Java guru along in a minute who'll know!).
I'd also double check the queue manager and ETC are properly registered with the transaction coordinator (Weblogic?).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 18, 2006 4:08 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you really want to achieve guaranteed once only delivery you need multiple things to work in concert...
- MQ guaranteed once only delivery comes at a price: persistent messages...
- Correct transactional control: Usually this is done by having the qmgr on the same box as the web server. It may also be achieved using the ETC.
The default settings for that would be on the connection factory(XA enabled) and the session. We use Session.AUTO_ACKNOWLEDGE.
According to the manual the transaction setting of the MDB will override any transactional setting passed to the session being created by it. (WAS) Don't know how that applies to BEA.
Now you should be able to run your multi-phase commit session without problems.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 18, 2006 11:52 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
| It may also be achieved using the ETC. |
Which KaiW (according to the 1st post) has. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| KaiW |
| Posted: Tue Dec 19, 2006 1:24 am Post subject: |
|
|
Newbie
Joined: 18 Dec 2006
Posts: 5
|
Ok, so I understand that a container managed tx is not required to assure exactly once delivery and that a createQueueSession(false, Session.AUTO_ACKNOWLEDGE); is sufficient.
Btw. I found out why the transaction was not committed, I forgot the session.commit()
Thanks to the grand masters  |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Dec 19, 2006 1:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| KaiW wrote: |
| Btw. I found out why the transaction was not committed, I forgot the session.commit() |
I said you had control! I answered a Java query correctly! Yay me! 
And yay you for getting it sorted out.
| KaiW wrote: |
| Thanks to the grand masters |
You're most welcome.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
