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 IndexMultiphase Commitclient and ccdt and ...

Post new topicReply to topic Goto page 1, 2  Next
client and ccdt and ... View previous topic :: View next topic
Author Message
jcv
PostPosted: Fri Dec 28, 2012 2:34 am Post subject: client and ccdt and ... Reply with quote

Chevalier

Joined: 07 May 2007
Posts: 409
Location: Zagreb

http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/cs11550_.htm
Quote:
WebSphere Application Server Version 6 and later includes a WebSphere MQ messaging provider, so you do not need to use the extended transactional client.


Can normal (ie not extended transactional) mq client v7 participate as two-phase commitable XA resource in transactions coordinated by WAS 8 transaction manager, by using JTA UserTransaction interface, and does usage of CCDTs on QCFs change anything with respect to that question?
Back to top
View user's profile Send private message Visit poster's website
zpat
PostPosted: Fri Dec 28, 2012 2:45 am Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5669
Location: UK

WAS includes a version of the ETC.

If you want to use ETC features outside of WAS, you can install the separate ETC (which is now free of charge).

If you want to know exactly which version of MQ client comes with which version of WAS there is a web page somewhere with this info on it.

AFAIK, the use (or non-use) of a CCDT has no effect on XA coordination.
Back to top
View user's profile Send private message
jcv
PostPosted: Fri Dec 28, 2012 7:19 am Post subject: Reply with quote

Chevalier

Joined: 07 May 2007
Posts: 409
Location: Zagreb

http://www-01.ibm.com/support/docview.wss?uid=swg27035452&aid=1
http://www-01.ibm.com/support/docview.wss?uid=swg27035714&aid=1

If I understand this properly, according to these two documents, when CCDT is used to configure connections to a group of separate queue managers, then somehow XA is not supported. The same holds for connection factories as well as for activation specifications. I wonder what the word "separate" means in this context? If I wanted connections to the same qmgr, I probably wouldn't use CCDT at all.
Back to top
View user's profile Send private message Visit poster's website
zpat
PostPosted: Fri Dec 28, 2012 8:33 am Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5669
Location: UK

From a quick glance that seems to be related to auto-reconnection and multi-instance queue managers.

CCDTs are still useful to avoid having to code the QM connection details in many different places.

If you don't use a CCDT, at least set up a DNS alias entry for your queue manager address so you can change where it runs later without having to reconfigure every reference to it.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Dec 28, 2012 9:56 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8382
Location: US: west coast, almost. Otherwise, enroute.

jcv wrote:
If I understand this properly, ...when CCDT is used to configure connections to a group of separate queue managers, then somehow XA is not supported.

Nope. XA itself has nothing to do with channels or CCDT.
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
mqjeff
PostPosted: Fri Dec 28, 2012 10:08 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

bruce2359 wrote:
jcv wrote:
If I understand this properly, ...when CCDT is used to configure connections to a group of separate queue managers, then somehow XA is not supported.

Nope. XA itself has nothing to do with channels or CCDT.


Nope, that's not true.

XA involves combining transactions against one or more specific resource managers - a specific queue manager, a specific database, etc. - together.

If you define a connection to a queue manager such that it does *NOT* point to a *specific* queue manager, but can instead connect to several different queue managers, and can *reconnect* to a different queue manager after a *failure*, then you can not construct an XA connection.

One typical use of a CCDT is to allow you to define a connection to a queue manager such that it does not point to a *specific* queue manager, but instead points to a group of queue managers that can be connected to in a load-balanced way such that a reconnect will choose a *different* queue manager.

So, yes, XA and CCDTs have interactions and can interfere with each other.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Dec 28, 2012 10:11 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8382
Location: US: west coast, almost. Otherwise, enroute.

mqjeff wrote:
bruce2359 wrote:
jcv wrote:
If I understand this properly, ...when CCDT is used to configure connections to a group of separate queue managers, then somehow XA is not supported.

Nope. XA itself has nothing to do with channels or CCDT.


Nope, that's not true.

XA involves combining transactions against one or more specific resource managers - a specific queue manager, a specific database, etc. - together.

If you define a connection to a queue manager such that it does *NOT* point to a *specific* queue manager, but can instead connect to several different queue managers, and can *reconnect* to a different queue manager after a *failure*, then you can not construct an XA connection.

One typical use of a CCDT is to allow you to define a connection to a queue manager such that it does not point to a *specific* queue manager, but instead points to a group of queue managers that can be connected to in a load-balanced way such that a reconnect will choose a *different* queue manager.

So, yes, XA and CCDTs have interactions and can interfere with each other.

XA is a qmgr and resource manager configuration issue, and not related to channels or CCDT, as the OP misunderstood.

Yes, a CCDT could allow an app to reconnect to a non-XA qmgr; but this is a configuration issue, and not a CCDT issue.
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
mqjeff
PostPosted: Fri Dec 28, 2012 11:26 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

bruce2359 wrote:
Yes, a CCDT could allow an app to reconnect to a non-XA qmgr; but this is a configuration issue, and not a CCDT issue.


No.

A CCDT configured using a qmgr group could allow the Transaction Manager to RECONNECT to a different queue manager during an attempt to reconcile a transaction, where the *current transaction* was *not in progress* on the queue manager being reconnected to.

That's why you can't combine the two of them.

Yes, it's a configuration issue.

But it's an issue with how the CCDT is configured, not with how the queue manager is configured.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Fri Dec 28, 2012 1:41 pm Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7535

http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzaf.doc/cs11600_.htm

Towards the end it says:
Quote:

If a client application starts an MQI channel first, the value of the QMgrName parameter on the MQCONN or MQCONNX call can be blank or a single asterisk (*), or it can start with an asterisk. Under these circumstances, however, you must ensure that the queue manager to which the application connects is the same as the queue manager that the transaction manager intends to open as a resource manager when it calls xa_open subsequently on the same thread. You might encounter fewer problems, therefore, if the value of the QMgrName parameter identifies the queue manager explicitly by name.


So, how does one "ensure that the queue manager to which the application connects is the same as the queue manager that the transaction manager intends to open as a resource manager when it calls xa_open subsequently on the same thread."?

I had hoped to find some examples showing how an ETC could use a CCTD with multiple QMs available to connect to, with some what if scenarios, but came up empty. A good topic for a Developerworks article...
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Dec 28, 2012 2:00 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8382
Location: US: west coast, almost. Otherwise, enroute.

mqjeff wrote:
bruce2359 wrote:
Yes, a CCDT could allow an app to reconnect to a non-XA qmgr; but this is a configuration issue, and not a CCDT issue.


No.

A CCDT configured using a qmgr group could allow the Transaction Manager to RECONNECT to a different queue manager during an attempt to reconcile a transaction, where the *current transaction* was *not in progress* on the queue manager being reconnected to.

That's why you can't combine the two of them.

Yes, it's a configuration issue.

But it's an issue with how the CCDT is configured, not with how the queue manager is configured.

Agreed.
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
jcv
PostPosted: Sun Dec 30, 2012 2:31 am Post subject: Reply with quote

Chevalier

Joined: 07 May 2007
Posts: 409
Location: Zagreb

So mq client automatic reconnection and XA global transaction conflict in a scenario described by Jeff, but there are "not happy day" scenarios in which they just complement each other without any conflict.

For example, when qmgr votes it is prepared to commit and db server says no, TM orders rollback/backout, and XA fulfilled its mission and everyone is happy. Or when some actor detects mqrc connection broken prior to the start of XA global transaction, it acquires valid connection to another qmgr and XA TM has clean fresh start with two sound RMs.

Again, client reconnection mission is fulfilled and everyone is happy. So why not trying to reconcile these two by making client aware it is already a part of XA global transaction, and allowing TM only to reconnect to the same qmgr in that case, while retaining his good quality in others?

Because the simplest and most unsatisfactory answer to Peter's question is not to use client auto reconnection to another qmgr feature together with XA.

I know that to discuss such matter in a competent manner it requires precise knowledge of what actors exist (for example XA model defines 3 of them: AP,RM,TM) and what actor perfoms exactly what actions, so maybe I don't picture it precisely.

And I hope noone gets offended by me asking such questions after really little study done in that direction, when whole teams spent significantly much more time to study it before me, and finally to create a product, while I'm just, you know, trying to use that product.
Back to top
View user's profile Send private message Visit poster's website
bruce2359
PostPosted: Sun Dec 30, 2012 7:09 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8382
Location: US: west coast, almost. Otherwise, enroute.

jcv wrote:

Again, client reconnection mission is fulfilled and everyone is happy.

Technically, only the participants in the transaction are happy. The other apps and RMs are are completely unaware.

jcv wrote:
So why not trying to reconcile these two by making client aware it is already a part of XA global transaction, and allowing TM only to reconnect to the same qmgr in that case, while retaining his good quality in others?

TMs don't connect or reconnect.

jcv wrote:
Because the simplest and most unsatisfactory answer to Peter's question is not to use client auto reconnection to another qmgr feature together with XA.

Yes, it is a responsibility of application that intends to reconnect (to an in-flight UofW) in order to continue with the transaction to reconnect to the qmgr with which it has the UofW.

The application is given the connection handle by the qmgr, and can know the qmgr name with the MQINQ. This presumes that the qmgr is still alive.

jcv wrote:
I know that to discuss such matter in a competent manner it requires precise knowledge of what actors exist (for example XA model defines 3 of them: AP,RM,TM) and what actor perfoms exactly what actions, so maybe I don't picture it precisely.

You seem to grasp the challenge of wmq client-based XA apps, and the risks.

jcv wrote:
And I hope noone gets offended by me asking such questions after really little study done in that direction, when whole teams spent significantly much more time to study it before me, and finally to create a product, while I'm just, you know, trying to use that product.

If I may speak (type?) for the lot of us, we are not offended.
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Sun Dec 30, 2012 11:23 am Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7535

bruce2359 wrote:


jcv wrote:
So why not trying to reconcile these two by making client aware it is already a part of XA global transaction, and allowing TM only to reconnect to the same qmgr in that case, while retaining his good quality in others?

TMs don't connect or reconnect.


This is way outside my area of expertise. I've never configured an ETC personally, so I'm participating more to learn.

http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzaf.doc/cs11600_.htm
Quote:
When the client application calls MQCONN or MQCONNX subsequently on the same thread that the transaction manager used to issue the xa_open call, the application receives a connection handle for the MQI channel that was started by the xa_open call. A second MQI channel is not started. The extended transactional client checks that the value of the QMgrName parameter on the MQCONN or MQCONNX call is the name of the queue manager at the server end of the MQI channel.


This implies to me that TMs do connect to the QM. THey never use that word "connect", but if the TM uses the xa_open call to initiate communications with a QM, and it results in an active instance of a SVRCONN channel, isn't that a MQCONNX under the covers?

And if both the app and TM are then client connected to QM1 over the same SVRCONN channel, and network connectivity to QM1 is interrupted long enough for either the TM or the app to try and connect to QM2, what happens? How do you insure the app and the TM are in sync when abandoning QM1 and going to QM2?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Sun Dec 30, 2012 12:20 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8382
Location: US: west coast, almost. Otherwise, enroute.

PeterPotkay wrote:
bruce2359 wrote:


jcv wrote:
So why not trying to reconcile these two by making client aware it is already a part of XA global transaction, and allowing TM only to reconnect to the same qmgr in that case, while retaining his good quality in others?

TMs don't connect or reconnect.


This is way outside my area of expertise. I've never configured an ETC personally, so I'm participating more to learn.

http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzaf.doc/cs11600_.htm
Quote:
When the client application calls MQCONN or MQCONNX subsequently on the same thread that the transaction manager used to issue the xa_open call, the application receives a connection handle for the MQI channel that was started by the xa_open call. A second MQI channel is not started. The extended transactional client checks that the value of the QMgrName parameter on the MQCONN or MQCONNX call is the name of the queue manager at the server end of the MQI channel.


This implies to me that TMs do connect to the QM. THey never use that word "connect", but if the TM uses the xa_open call to initiate communications with a QM, and it results in an active instance of a SVRCONN channel, isn't that a MQCONNX under the covers?

And if both the app and TM are then client connected to QM1 over the same SVRCONN channel, and network connectivity to QM1 is interrupted long enough for either the TM or the app to try and connect to QM2, what happens? How do you insure the app and the TM are in sync when abandoning QM1 and going to QM2?

I'm going to partially retract my 'TMs don't connect or reconnect' statement. Part of the XA handshake and registration can/will cause the TM to (re)connect to RMs. The circumstances under which TMs do this is documented earlier in the URL thread. Read backward in the URL thread.
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
jcv
PostPosted: Wed Jan 02, 2013 1:48 am Post subject: Reply with quote

Chevalier

Joined: 07 May 2007
Posts: 409
Location: Zagreb

How exactly is this implemented?

Is there a possibility for a TM to connect to the "wrong" qmgr constantly on regular basis, presenting thus an obstacle to normal functioning which otherwise would not exist (if there was not such CCDT configuration)? That would be a problem. If not, and if qmgr implicitly does backout in cases when it is not instructed explicitly by TM to commit, I don't see how exactly TM reconnection to the "wrong" qmgr only in exceptional cases may present bigger issue than possible unneccessary rollback/backout/abort of XA transaction which would otherwise be reconciled. Because, what else can TM do when it learns that there is no such transaction that it tries to reconcile, on a qmgr that it is reconnected?
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:
Post new topicReply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum IndexMultiphase Commitclient and ccdt and ...
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.