I have done the Websphere MQ integration with jboss in the past and ran into the same issues. It's not you and it's not jboss. The JMS ASF spec is a little weak in describing who/how the inbound XA transaction gets started.
The only way JBossMQ was able to implement the ASF spec was by starting the transaction without an associated XID. Once the message gets delivered to the container, JBossMQ allows the container to associate an XID with the session. The session then assigns the XID to the TX that delivered the message. JBossMQ had to kind of jump through hoops to get this to work.
It would have been much easier to allow JBossMQ to assign an XID to the transaction to begin with. WebSphere MQ might be trying to do something like that. But since it's not in the JMS ASF spec, IBM would need to tell us what MQ is expecting (outside the spec) to get the asynch message delivery to work.
Other ways to skin this cat:
- Don't use the current MDB container invoker (which uses the ASF to do asynch message delivery). Write a new MDB container invoker that does synchronous Receiver.receive() calls to get messages. The problem with this approach is that you need to start a JTA TX before you do the receive() and our current TM will timeout the TXs that take too long. A solution my be to use receiveNoWait() instead.
- Implement a MDB conatiner invoker using the new JCA TX inflow stuff. I have not had time to look into this yet or if MQ has a JCA resource adapter but this would be the best solution.
Regards, Hiram
[EMAIL PROTECTED] wrote:
Thanks a lot I really appreciate the answer. I was not so confused after all :-)
As soon as I am trying to use a WebSphere MQ XA connection factory, my MDB never receive any messages. Any pointers on which JBoss classes I should look at/trace through to understand where the problem might be?
I do believe that it is an MDB related problem since I am able to do 2PC with a WebSphere MQ queue using an XA connection factory when it is done from within the MDB onMessage method (I configured an XA connector like the JmsXA one but for WS MQ).
Thomas
-----Original Message-----
From: hiram [mailto:[EMAIL PROTECTED] Sent: Monday, June 09, 2003 6:43 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] XA connection factory for an MDB
Hi Thomas,
[EMAIL PROTECTED] wrote:
My limited knowledge of MDB internals and XA is getting me confused.
The basic question that I have is "for what purpose do I need an XA connection factory for an MDB?"
To get a 2 phase commit between all the resources involved in the tranasaction.
Initially, my answer was as follow: If I deploy my MDB with container managed transaction and transaction required, and if the implementation of my onMessage method is accessing an external resource that I want to synchronize through XA with the reading of the message by the MDB, then I need the MDB to use an XA connection factory (so all the resources involved in the transaction are XA "enabled").
yes you are correct.
I did some testing with JBoss and it seems that even if my MDB is not using an XA transaction, everything is working ok:
- I have a MDB listening to a WebSphere MQ queue and not using an XA connection factory.
good job.
- My onMessage operation is sending a message to a JBoss queue in a transacted session using the JmsXA connection factory.
- If I generate an abort in my onMessage method (mdbContext.setRollbackOnly ()), then the rollback is done on the JBoss queue and on the MDB queue.
That is correct. The JBoss MDB contaier was created knowing that it would not allways be able to work with an XA connection to get it's messages. If the MDB does not have XA jms provider, it will manually commit/rollback the jms transaction (using Session.commit()/Session.rollback()).
So, either I do not need an XA connection factory for my MDB (and then is there any cases where I will need one), either the fact that it is
Not strictly needed.
working on JBoss is for some kind of other reason and I am not doing true XA between the MDB queue and the JBoss one and in some cases (according to where/when the abort is occurring), my transaction integrity between the 2 queues might not be respected.
That's exactly what is going on. The XA transaction is being commited/rolledback and then the MQSeries TX is being commited/rolledback. So you do run the risk of of lossing integrity.
Anyone with a good answer/explanation?
Thomas
Regards, Hiram
------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
