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 IndexUser ExitsAPI exit to capture xa_prepare and xa_commit

Post new topicReply to topic
API exit to capture xa_prepare and xa_commit View previous topic :: View next topic
Author Message
amey
PostPosted: Sun May 22, 2016 10:42 pm Post subject: API exit to capture xa_prepare and xa_commit Reply with quote

Newbie

Joined: 22 May 2016
Posts: 2

Hi,

Currently I have configured my queue manager to use the sample exit module provided my IBM "amqsaxe".

My application program performs an XA transaction with WMQ & DB2 as transaction participants.

The log file folder has set permission "777" for all the users so that "mqm" wil be able to create its log file.
I am able to see all the events in log file generated by API exit, such as MQBEGIN, PutBefore, PutAfter, CommitBefore and CommitAfter etc.


though my application is performing XA transaction, i am not able to see "xa_prepare" or "xa_commit" functions being called in any of the log files (generated with my user and also generated by "mqm").


Can anyone please tell me in which scenario the functions "xa_prepare" and "xa_commit" will be called and logged in the API exit log file ?
Back to top
View user's profile Send private message
Andyh
PostPosted: Sun May 22, 2016 11:57 pm Post subject: Reply with quote

Centurion

Joined: 29 Jul 2010
Posts: 148

The xa_prepare and xa_commit API exit calls will be invoked if MQ is involved in an XA transaction as a resource manager.
In the case you state, MQ is acting as the transaction manager and so the
API call being made in that case is MQCMIT and you are correctly seeing the API exit called for CommitBefore and CommitAfter.

If, for example, DB2 provided an API exit then it would be reasonable for DB's xa_prepare and xa_commit API exit points to be called.
An alternate example would be if, say, WAS was the transaction manager in which case MQ's xa_prepare and xa_commit entry points would be called by WAS, and the relevant API exits would then be invoked by MQ.
Back to top
View user's profile Send private message
yashgt
PostPosted: Mon May 23, 2016 12:45 am Post subject: Reply with quote

Apprentice

Joined: 11 Nov 2014
Posts: 38

In the above case MQ is transaction manager as well as resource manager. Hence it is expected that XA_prepare will be called.
Back to top
View user's profile Send private message
amey
PostPosted: Mon May 23, 2016 1:06 am Post subject: Reply with quote

Newbie

Joined: 22 May 2016
Posts: 2

Quote:


The xa_prepare and xa_commit API exit calls will be invoked if MQ is involved in an XA transaction as a resource manager.
In the case you state, MQ is acting as the transaction manager and so the
API call being made in that case is MQCMIT and you are correctly seeing the API exit called for CommitBefore and CommitAfter.

If, for example, DB2 provided an API exit then it would be reasonable for DB's xa_prepare and xa_commit API exit points to be called.
An alternate example would be if, say, WAS was the transaction manager in which case MQ's xa_prepare and xa_commit entry points would be called by WAS, and the relevant API exits would then be invoked by MQ


@Andyh

I am able to see "Comitbefore" and "ComitAfter" function calls in the log file generated by my application program and not in the log file created by MQ server (mqm).

As you said "xa_prepare and xa_commit API exit calls will be invoked if MQ is involved in an XA transaction as a resource manager", in my case, MQ is acting as a transaction manager and also a resource manager. Also my application is performing XA transaction, but still I am not able to see calls to "xa_prepare" or "xa_commit" in the generated log file.

In my test program we are using MQAPI's ( MQBEGIN() and MQCMIT()).
Is there any different implementation to be used or any additional options to be set in the code so that "xa_prepare" and "xa_comit" will be called?
Back to top
View user's profile Send private message
Andyh
PostPosted: Mon May 23, 2016 3:27 am Post subject: Reply with quote

Centurion

Joined: 29 Jul 2010
Posts: 148

Although MQ is acting as both a TM and an RM, in this case there are no external calls to the MQ RM, and hence the API exit is not driven for the XA calls. The API exit reflects the external 'API' calls into MQ, not the internal API's driven as a consequence of those external calls.
Back to top
View user's profile Send private message
yashgt
PostPosted: Mon May 23, 2016 8:53 am Post subject: Reply with quote

Apprentice

Joined: 11 Nov 2014
Posts: 38

Any suggestions for intercepting the XA_ calls made to the MQ Resource Manager?
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon May 23, 2016 9:18 am Post subject: Reply with quote

Poobah

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

yashgt wrote:
Any suggestions for intercepting the XA_ calls made to the MQ Resource Manager?

For what purpose? What will you do in the XA calls? Is there a problem?
_________________
I didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
yashgt
PostPosted: Mon May 23, 2016 8:48 pm Post subject: Reply with quote

Apprentice

Joined: 11 Nov 2014
Posts: 38

Hi,

We are observing the behaviour of the application in the event of failure. We would like to crash the system in the middle of a transaction, ideally in such a bad state that the XA transaction becomes in-doubt. The XA transaction in our case involves a DB and an MQ. The Transaction Coordinator is the MQ Server.

We would like to invoke something like exit() when the MQ Resource Manager is asked to commit after the DB has already committed. Getting the system into an inconsistent state is our goal. Of course this will not be done in a production system. This is a test system. Then we want to recover the system and bring it into a consistent state by manually rolling forward or backward the in-doubt transaction.
Back to top
View user's profile Send private message
tczielke
PostPosted: Tue May 24, 2016 4:09 am Post subject: Reply with quote

Yatiri

Joined: 08 Jul 2010
Posts: 656
Location: Illinois, USA

yashgt wrote:
Hi,

We are observing the behaviour of the application in the event of failure. We would like to crash the system in the middle of a transaction, ideally in such a bad state that the XA transaction becomes in-doubt. The XA transaction in our case involves a DB and an MQ. The Transaction Coordinator is the MQ Server.

We would like to invoke something like exit() when the MQ Resource Manager is asked to commit after the DB has already committed. Getting the system into an inconsistent state is our goal. Of course this will not be done in a production system. This is a test system. Then we want to recover the system and bring it into a consistent state by manually rolling forward or backward the in-doubt transaction.


If this is a Unix queue manager and you are using persistent messages, you could try this. However, it would only be appropriate for a queue manager where you do not care about the work (i.e. sandbox queue manager).

DO NOT DO THIS ON A REAL QUEUE MANAGER!

1) Get to the point in your code where you are about to do the MQCMIT
2) Use the kill command to send a stop signal to the amqzmuc0 process. This is the process that writes out to the MQ recovery log.
3) Enter into your application MQCMIT
4) Check if DB2 has completed its part of the transaction
5) Kill the queue manager, entirely.

I don't know if the above would work or not, but I would give it a try for your use case. The MQ part of the transaction will not be able to complete because the logger will be stopped and unable to write out to the recovery log.
_________________
MQ administrator since 2010.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue May 24, 2016 5:39 am Post subject: Reply with quote

Poobah

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

yashgt wrote:
Hi,

We are observing the behaviour of the application in the event of failure. We would like to crash the system in the middle of a transaction, ideally in such a bad state that the XA transaction becomes in-doubt. The XA transaction in our case involves a DB and an MQ. The Transaction Coordinator is the MQ Server.

We would like to invoke something like exit() when the MQ Resource Manager is asked to commit after the DB has already committed. Getting the system into an inconsistent state is our goal. Of course this will not be done in a production system. This is a test system. Then we want to recover the system and bring it into a consistent state by manually rolling forward or backward the in-doubt transaction.

So, you or your management doubt that XA-compliant TMs and RMs two-phase commit protocols (the "ACID test") actually work?
_________________
I didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue May 24, 2016 11:11 am Post subject: Reply with quote

Poobah

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

yashgt wrote:
This is a test system. Then we want to recover the system and bring it into a consistent state by manually rolling forward or backward the in-doubt transaction.

Write a simple app that makes use of XA TM/RM.
The app should
- MQPUT a persistent message into a queue in syncpoint (unit of work)
- Insert a row into a DB in the same syncpoint (unit of work)
- Write a message to STDOUT
- Wait 30 seconds (time before the MQCMIT (or equivalent)
In the 30 seconds gap, power-off the server (or equivalent)

At restart, the qmgr (and DB2) will automatically perform log redo/undo, and the TM will automatically attempt to "complete" the transaction - by committing it (if it can) or by backing it out.

yashgt wrote:
...Then we want to recover the system and bring it into a consistent state by manually rolling forward or backward the in-doubt transaction.

Manually? At RM restart, the TM issuing the UofW id will automatically make the commit/backout determination based on what it knows about the transaction. If the RMs remain in-doubt, the TM usually has a command that you can issue to commit/backout.

I remain unclear about what you are trying to accomplish (demonstrate, prove, disprove). XA has been with us for decades.
_________________
I didn't know that Schrdinger had a cat.
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 IndexUser ExitsAPI exit to capture xa_prepare and xa_commit
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.