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 » General IBM MQ Support » Suspicious XA Transaction

Post new topic  Reply to topic
 Suspicious XA Transaction « View previous topic :: View next topic » 
Author Message
Hoeppie
PostPosted: Fri Mar 27, 2015 1:56 am    Post subject: Suspicious XA Transaction Reply with quote

Newbie

Joined: 08 Dec 2010
Posts: 4

HI,
we got an installation started from V5.2 to now V7.5.
An WAS and DB is working with MQ and has XA timeout of 300 sec.

With dspmqtrn we got one transaction on QM, which stays over weeks in-doubt. (this is on more than one QM with different gtrid)

Code:
AMQ7056: Transaction number 0,1 is in-doubt


After restart of all applications it is still there.

dmpmqlog gives:
Code:
HLG Header: lrecsize 236, version 1, rmid 0, eyecatcher HLRH

LogRecdType . . : AQM Soft Log Image (266)
Eyecatcher  . . : ALRH                 Version . . . . : 1
LogRecdLen  . . : 216                  LogRecdOwnr . . : 256    (AQM)
XTranid . . . . : TranType: XA
   XID: formatID 1463898948, gtrid_length 36, bqual_length 54
        gtrid
[000001323D8A0FFB0000000101764B2E0F85156422B9D9892660D245775FE1F129C714A6]
        bqual
[000001323D8A0FFB0000000101764B2E0F85156422B9D9892660D245775FE1F129C714A6000000010000000000000000000000000001]
QueueName . . . : NULL
Qid . . . . . . : {NULL_QID}
ThisLSN . . . . : <0:0:0:0>
PrevLSN . . . . : <0:0:0:0>

Version . . . . : 1
SLCount . . . . : 1

Soft Log Entry 0

Qid . . . . . . : {Hash 301349888, Counter: 5}
Index . . . . . : 1                    Reason  . . . . : 1026
(Unknown)

And we got 310 similar entries in dump.

Is it something to resolve with rsvmqtrn ?

I am puzzled how this happen.

Cheers hoeppie
Back to top
View user's profile Send private message
umatharani
PostPosted: Sat Mar 28, 2015 2:36 am    Post subject: Reply with quote

Apprentice

Joined: 23 Oct 2008
Posts: 39

Hi,

If the transaction is global then it is the responsibility of the TM to resolve it. In this case, I assume WAS is the TM. Any non global transactions are expected to be resolved during queue manager restart, but may not the Global transaction coordinated by TM. In this case, I think it is required to resolve using rsvmqtrn. Was this queue manager migrated from MQ V5.2 to MQ 7.5 and did this txn exist before migration?

Thanks,
mahesh
Back to top
View user's profile Send private message
zpat
PostPosted: Sat Mar 28, 2015 3:38 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5866
Location: UK

Maybe these are zombie transactions. There is an undocumented environment variable setting to expire these. Open a PMR first though.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
Andyh
PostPosted: Sat Mar 28, 2015 6:17 am    Post subject: Reply with quote

Master

Joined: 29 Jul 2010
Posts: 239

Zombie transactions cannot be in-doubt.
Zombie transactions are not visible in dspmqtrn.

As stated earlier, it is the transaction managers responsibility to resolve these transactions. When the instance of WAS that created the transaction resynchronizes with the queue manager the transaction should be automatically resolved. Have you made any changes to you configuration that would explain why this resync hasn't happened ?

As you mention you've got 310 such transactions then it appears whatever you are doing is happening repeatedly.

I would only recommend manually resolving the transaction with rsvmqtrn in the event that you are unable to get MQ and WAS to resync, for example if the WAS instance that created the transaction has been deleted.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Sat Mar 28, 2015 1:18 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Andyh wrote:

I would only recommend manually resolving the transaction with rsvmqtrn in the event that you are unable to get MQ and WAS to resync, for example if the WAS instance that created the transaction has been deleted.


Or the pending transactions have been deleted from the WAS instance in order to allow the WAS instance to restart.

Check your WAS setup. There should be there something like information about ID to use with resource manager to solve pending transactions at restart. This may not be the same ID as the one on your regular qcf and may have more privileges. Remember it being there for JDBC, don't know for messaging though... If this user information is not populated WAS may not be able to connect at pre-startup and resolve pending transactions before being open for business...

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Hoeppie
PostPosted: Wed Apr 01, 2015 12:55 am    Post subject: Reply with quote

Newbie

Joined: 08 Dec 2010
Posts: 4

Hi,
on WAS-Side we found no transaction with this id.

The transaction number 0,1 I think means that 0 stands for MQ as coordinator. Ans there are no AMQ7107 messages.

I was thinking that all transactions where cleaned when I shutdown every component (MQ, WAS and DB) at same time and start up again. That happened during new deployment on WAS and update db-schema for new release.

The migration was done on regular basis on keeping data and log directories. V5.2 to V6.0 to V7.1 and then at last to V7.5. I can see only the actual state and can see errorlogs from 2014.

I found an old issue that in version was a problem to clean old tranlogs after restart with version 5.2 and 6.0. Years ago.

We decided now to use rsvmqtrn and see what happened. When I got the results I will post them.

Thank's for your help.
Back to top
View user's profile Send private message
Hoeppie
PostPosted: Tue Apr 21, 2015 1:28 am    Post subject: Reply with quote

Newbie

Joined: 08 Dec 2010
Posts: 4

The command rsvmqtrn with -a changed nothing.
This in-doubt is still there.

Update: On two qmgrs it resolved the transaction.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Apr 21, 2015 5:15 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Hoeppie wrote:
The command rsvmqtrn with -a changed nothing.
This in-doubt is still there.

Update: On two qmgrs it resolved the transaction.

Which way did you resolve the transaction? Force commit or rollback?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Hoeppie
PostPosted: Thu Apr 23, 2015 12:15 pm    Post subject: Reply with quote

Newbie

Joined: 08 Dec 2010
Posts: 4

There was no distributed XA-Transaction (the manager is a WAS) and a
new installation.
We checked as well the channel status.
DISPLAY CHSTATUS(*) ALL
And found no in-doubt.

Finally we resolved the transactions with:
rsvmqtrn -c 0,1

Nothing lost.
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 » General IBM MQ Support » Suspicious XA Transaction
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.