| Author |
Message
|
| Long John Silver |
 Posted: Wed May 12, 2010 7:39 am Post subject: XA with JMS and WMQ as coordinator in a Java SE environment |
 |
|
Newbie
Joined: 12 May 2010
Posts: 9
|
Hi all,
It's my first post here, so be patient 
I need to perform an XA transaction between WMQ 7 and Oracle 10G into an application which uses the JMS libraries.
The only example I found with WMQ acting as coordinator is:
http://www.ibm.com/developerworks/websphere/library/techarticles/0601_ritchie/0601_ritchie.html
Actually in the above example they are using the plain Java classes for MQ, so to begin and then commit the transaction they use directly the QManager.
In my case I use the JMS paradigm so I have no notion of the MQManager but I get all the objects through the MQQueueConnectionFactory.
All samples with JMS uses an external coordinator (aka AS) but in my case my application is running in a Java Standard Edition env.
Could you give me some hint?  |
|
| Back to top |
|
 |
| mvic |
| Posted: Wed May 12, 2010 8:24 am Post subject: Re: XA with JMS and WMQ as coordinator in a Java SE environm |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Long John Silver wrote: |
| Could you give me some hint? |
When a queue manager is the co-ordinator, you need access to the MQBEGIN call (C language) or MQQueueManager.begin() method (Java language). In a JMS app you have neither of these.
So I think you have to write the application using the non-JMS classes. |
|
| Back to top |
|
|
| Long John Silver |
| Posted: Wed May 12, 2010 8:45 am Post subject: Re: XA with JMS and WMQ as coordinator in a Java SE environm |
|
|
Newbie
Joined: 12 May 2010
Posts: 9
|
| mvic wrote: |
When a queue manager is the co-ordinator, you need access to the MQBEGIN call (C language) or MQQueueManager.begin() method (Java language). In a JMS app you have neither of these.
So I think you have to write the application using the non-JMS classes. |
Digging into Google searches and IBM Javadocs a thought hit me...
All the samples I found with JMS/XA involved use the UserTransaction object but it means that there is an external coordinator.
The problem here is that the application already exist and works perfectly with JMS. Now, for a new feature, I need XA and a simple add-on is becoming a nightmare.
So the XAQueueConnection returned from the MQXAQueueConnectionFactory is not meant to be used by the user. I have no means to specify the other XADatasource which participate to the XA transaction as in:
theQueueManager.getJDBCConnection(xads) |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed May 12, 2010 2:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you are trying to do a multiphase commit in a standard Java SE environment you are more or less SOL. The reason for it is that you will need to have an environment supporting a J2EE TransactionController and J2EE DataSources.
All these are easy to secure in a J2EE env but very difficult to obtain and use correctly in a J2SE environment. You quickly move from lightweight to heavyweight.
Now as you are talking about Oracle 10 g, you can either write the app in Java base and use the qmgr as transaction coordinator or run it inside of Oracle's J2EE appserver as a J2EE app. Be aware of multiphase commit limitations if the qmgr is not on the same box as the DB or the J2EE App.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mvic |
| Posted: Wed May 12, 2010 2:19 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Quote: |
| you will need to have an environment supporting a J2EE TransactionController and J2EE DataSources. |
The article linked by the OP seems to show it can be done without J2EE components. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed May 12, 2010 2:30 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mvic wrote: |
| Quote: |
| you will need to have an environment supporting a J2EE TransactionController and J2EE DataSources. |
The article linked by the OP seems to show it can be done without J2EE components. |
| fjb_saper wrote: |
| Now as you are talking about Oracle 10 g, you can either write the app in Java base and use the qmgr as transaction coordinator or run it inside of Oracle's J2EE appserver as a J2EE app. Be aware of multiphase commit limitations if the qmgr is not on the same box as the DB or the J2EE App. |
I did not say that it could not be done. I said that it was very difficult and unpractical to try to do it in standalone JMS outside of a J2EE environment. The article reference by the OP shows the example in java base, not JMS as requested by the OP.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mvic |
| Posted: Wed May 12, 2010 2:47 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| fjb_saper wrote: |
| I did not say that it could not be done. I said that it was very difficult and unpractical to try to do it in standalone JMS outside of a J2EE environment. The article reference by the OP shows the example in java base, not JMS as requested by the OP. |
The OP is running J2SE. I therefore assumed they did not have the option of J2EE, and needed the queue manager to co-ordinate the units of work. If my assumptions are wrong then my conclusions are unsafe too - but I think they are correct given what was written in the OP.
So, the queue manager would be the co-ordinator. You cannot do this in a JMS J2SE application, because you don't have a MQQueueManager upon which to call the .begin() method.
So (sadly) it doesn't matter if the OP is using JMS now, they cannot continue to use JMS from J2SE and get the queue manager to co-ordinate a database via XA.
If the OP can use J2EE then I agree that this would be a cleaner option. |
|
| Back to top |
|
|
| Long John Silver |
| Posted: Thu May 13, 2010 1:08 am Post subject: |
|
|
Newbie
Joined: 12 May 2010
Posts: 9
|
Hi all,
You are both correct 
When we wrote the application we did not have XA requirements so we underestimated the problem writing everything with the JMS paradigm (perfectly legal in a JSE environment).
It's a shame that IBM did not implement XA support somehow using JMS classes and MQManager as coordinator.
Now, given that the application is already deployed and running, a total rewrite using the base Java MQ classes is not feasible.
Giving that I need the XA for a single message sent once a day and being currently SOL my only solution now is just to browse the message without removing it, saving it on the DB and then removing the message, actually a poor man solution 
Thanks |
|
| Back to top |
|
|
| mvic |
| Posted: Thu May 13, 2010 2:10 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Long John Silver wrote: |
It's a shame that IBM did not implement XA support somehow using JMS classes and MQManager as coordinator.
Now, given that the application is already deployed and running, a total rewrite using the base Java MQ classes is not feasible. |
Imagine IBM wrote some extensions to make this possible.
Why did you choose JMS? Presumably it was because you would like the ability later to move your program to another messaging provider, instead of MQ.
In the imagined case where you coded the app to make some extra calls to the extended API, your JMS application would not be JMS any more. I mean, you would not be able later to move it to another messaging provider. You would have lost the benefit of using the JMS API in the first place.
If you want facilities offered by MQ that are not included in JMS, you have to use MQ's other APIs.
| Quote: |
| Giving that I need the XA for a single message sent once a day |
One message once a day... XA (with all its programming and setup costs) would be a big solution to this small problem. |
|
| Back to top |
|
|
|
|
