| Author |
Message
|
| Hoeppie |
 Posted: Fri Mar 27, 2015 1:56 am Post subject: Suspicious XA Transaction |
 |
|
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 |
|
 |
| umatharani |
| Posted: Sat Mar 28, 2015 2:36 am Post subject: |
|
|
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 |
|
|
| zpat |
| Posted: Sat Mar 28, 2015 3:38 am Post subject: |
|
|
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 |
|
|
| Andyh |
| Posted: Sat Mar 28, 2015 6:17 am Post subject: |
|
|
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 |
|
|
| fjb_saper |
| Posted: Sat Mar 28, 2015 1:18 pm Post subject: |
|
|
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 |
|
|
| Hoeppie |
| Posted: Wed Apr 01, 2015 12:55 am Post subject: |
|
|
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 |
|
|
| Hoeppie |
| Posted: Tue Apr 21, 2015 1:28 am Post subject: |
|
|
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 |
|
|
| fjb_saper |
| Posted: Tue Apr 21, 2015 5:15 am Post subject: |
|
|
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 |
|
|
| Hoeppie |
| Posted: Thu Apr 23, 2015 12:15 pm Post subject: |
|
|
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 |
|
|
|
|
