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 CommitXA transaction for remote queue

Post new topicReply to topic
XA transaction for remote queue View previous topic :: View next topic
Author Message
karthick_3d
PostPosted: Fri Jun 10, 2016 6:41 am Post subject: XA transaction for remote queue Reply with quote

Newbie

Joined: 10 Jun 2016
Posts: 4

All,
I am new to this group. I was searching for some discussions around using XA transaction using Remote Queues. But I didnt manage to find exactly what I am after.
If I am creating a Remote Queue to drop a message to a different Queue manager using a sender/receiver channel, Would XA transaction work without any issues. i.e. if the transaction rollback at the end, would MQ ensures the message doesnt reach the remote Queue?

thanks
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Jun 10, 2016 6:58 am Post subject: Reply with quote

Poobah

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

A QRemote definition is not a queue. When the QR def is MQOPENed, subsequent MQPUTs are to a transmission queue (a QLocal with xmitq attribute). These MQPUTs may be in a UofW that the app MQCMITs or MQBACKs. Your UofW ends here.

The Sender Message Channel Agent moves the message from the transmission queue down the network to the Receiver MCA, which MQPUTs the message in the destination queue (or dead-letter-queue).
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
Vitor
PostPosted: Fri Jun 10, 2016 7:12 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 24972
Location: Ohio, USA

You need to think about what is included in the transaction's unit of work, and what's participating in terms of software. If you have (for example) the application, the queue manager and the database all synchronized through XA and you've put the message in the same unit of work as the database changes, then neither the put nor the database changes are committed until the transaction is committed. If the transaction is rolled back, all are rolled back.

Likewise, if the message can't be put (the xmitq is full) then the database changes would be rolled back. If the message wasn't put under syncpoint, then it wouldn't matter what happened to the transaction.

And none of this has any effect on the queue that is remote (i.e. where the remote queue is pointing).
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
karthick_3d
PostPosted: Fri Jun 10, 2016 8:51 am Post subject: Reply with quote

Newbie

Joined: 10 Jun 2016
Posts: 4

Thanks, I see it should work similar to a local queue participating in XA transaction. We have applications which would update multiple databases and MQ . So If there is a rollback due to any reason, local queue updates (GET/PUT) would rollback. I should expect the same behavior for remote queues as well. I will write some test application to test the same.
Back to top
View user's profile Send private message
Vitor
PostPosted: Fri Jun 10, 2016 9:06 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 24972
Location: Ohio, USA

karthick_3d wrote:
I should expect the same behavior for remote queues as well.


As my worthy associate points out, a qremote isn't a queue but an indirection point to a specific type of local queue. So of course it works the same as for the other type of local queue. A remote queue is a local queue hosted by a queue manager you're not connected to, and is unaffected by anything you do locally.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Tue Jun 14, 2016 10:59 pm Post subject: Reply with quote

Padawan

Joined: 25 Mar 2003
Posts: 1807
Location: Melbourne, Australia

karthick_3d wrote:
Thanks, I see it should work similar to a local queue participating in XA transaction. We have applications which would update multiple databases and MQ . So If there is a rollback due to any reason, local queue updates (GET/PUT) would rollback. I should expect the same behavior for remote queues as well. I will write some test application to test the same.

For putting messages to QREMOTE objects, the commit / rollback occurs on the transmission queue.

MQ conducts a separate UOW for the Message Channel Agent to deliver the message to the destination QLOCAL on the remote queue manager. So even after your app commits, the message still has to go through the MCA UOW before it is visible on the destination QLOCAL. If there are issues with starting or running channels, there may be a delay.
_________________
Glenn
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Jun 15, 2016 5:29 am Post subject: Reply with quote

Poobah

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

gbaddeley wrote:
karthick_3d wrote:
Thanks, I see it should work similar to a local queue participating in XA transaction. We have applications which would update multiple databases and MQ . So If there is a rollback due to any reason, local queue updates (GET/PUT) would rollback. I should expect the same behavior for remote queues as well. I will write some test application to test the same.

For putting messages to QREMOTE objects, the commit / rollback occurs on the transmission queue.

MQ conducts a separate UOW for the Message Channel Agent to deliver the message to the destination QLOCAL on the remote queue manager. So even after your app commits, the message still has to go through the MCA UOW before it is visible on the destination QLOCAL. If there are issues with starting or running channels, there may be a delay.

And, presuming that the consuming app MQGETs the message in SYNCPOINT (in a UofW), three separate and distinct UofW's take place:
UofW 1. The producing app MQPUTs the original message to the xmitq in SYNCPOINT.
UofW 2. The sending side MCA MQGETs the message from the xmitq, and transmits it down the network to the receiving side MCA, which MQPUTs the message into the destination queue (or Dead-Letter-Queue - all within the same SYNCPOINT.
UofW 3. The consuming app MQGETs the message from the destination queue in SYNCPOINT.
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexMultiphase CommitXA transaction for remote queue
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.