ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Multiphase Commit » XA with JMS and WMQ as coordinator in a Java SE environment

Post new topic  Reply to topic
 XA with JMS and WMQ as coordinator in a Java SE environment « View previous topic :: View next topic » 
Author Message
Long John Silver
PostPosted: Wed May 12, 2010 7:39 am    Post subject: XA with JMS and WMQ as coordinator in a Java SE environment Reply with quote

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
View user's profile Send private message
mvic
PostPosted: Wed May 12, 2010 8:24 am    Post subject: Re: XA with JMS and WMQ as coordinator in a Java SE environm Reply with quote

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
View user's profile Send private message
Long John Silver
PostPosted: Wed May 12, 2010 8:45 am    Post subject: Re: XA with JMS and WMQ as coordinator in a Java SE environm Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Wed May 12, 2010 2:06 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
mvic
PostPosted: Wed May 12, 2010 2:19 pm    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Wed May 12, 2010 2:30 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
mvic
PostPosted: Wed May 12, 2010 2:47 pm    Post subject: Reply with quote

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
View user's profile Send private message
Long John Silver
PostPosted: Thu May 13, 2010 1:08 am    Post subject: Reply with quote

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
View user's profile Send private message
mvic
PostPosted: Thu May 13, 2010 2:10 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Multiphase Commit » XA with JMS and WMQ as coordinator in a Java SE environment
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.