 | |
Remote LONGTX with no userthread in 9.30 UC6 W4
comp.databases.informix comp.databases.informix
 |
| | Thread Tools | Search this Thread | Display Modes |
#1
 
| |||
| |||
|
Remote LONGTX with no userthread in 9.30 UC6 W4 -
05-18-2004
, 11:16 AM
|
Message 3 in thread From: Jonathan Leffler Subject: Re: Remote LONGTX with no userthread in 9.30 UC6 W4 rdtbra wrote: We use here IDS 9.30.UC6W4, running in SunOS 5.7. Both Informix and Solaris are 32 bits. For the second time we have reached a situation where the instance shows a LONG TRANSACTION marked with flags --H--G and userthread 0. When this instance is started, after the fast recovery it instantly is signed as OnLine (LONGTX) and the second header line shows the instance as blocked. On our message file, there is an indication of a distributed transaction as follows: 17:42:04 Aborting Long Transaction: tx 0x83dceef8 no user info due to XA or distributed (2-phase commit) transaction 17:42:04 Aborting Long Transaction: tx 0x83dced28 no user info due to XA or distributed (2-phase commit) transaction 17:42:04 Session completed abnormally. Rolling back tx id 170, flags 0x108463b 17:42:04 Session completed abnormally. Rolling back tx id 80, flags 0x108463b 17:58:09 Aborting Long Transaction: tx 0x83dceb58 no user info due to XA or distributed (2-phase commit) transaction After this, the instance is blocked, and the following appeared in our message log: 20:29:30 Logical Recovery has reached the transaction cleanup phase. 20:29:30 Logical Recovery Complete. 0 Committed, 0 Rolled Back, 3 Open, 0 Bad Locks 20:29:31 Dataskip is now ON for all dbspaces 20:29:32 Checkpoint Completed: duration was 1 seconds. 20:29:32 Checkpoint loguniq 109671, logpos 0x15018 20:29:32 Maximum server connections 0 20:29:32 Blocking on XA transaction, tx 0x83dceb58, till it is cleaned up. 20:29:32 Blocking on XA transaction, tx 0x83dced28, till it is cleaned up. 20:29:32 Blocking on XA transaction, tx 0x83dceef8, till it is cleaned up. 20:29:32 On-Line Mode The only solution was to call 24x7, and the problem was solved. They used an utility to clear the transactions. Unfortunatelly there was a second occurrence yesterday. Additional information: Applications using Oledb with .NET. Applications using ODBC. Applications using ESQL/C. MTS - Microsoft Transaction Server/Service? Is anything on the client side using that? The only distributed transaction is a .NET application that opens two connections with the same instance but two different databases. Do you know if any other database servers are involved? Or is it all strictly local to the current IDS server? Of itself, two separate connections are simply two separate connections, but .NET might be making them into one XA transaction. In which case, the question is - why is the XA coordinator dying? Or, roughly equivalently - who is turning off their PC and not restarting it? Or who's machine is BSoD'ing and not rebooting in a timely manner? Who's cleaning lady pulls the plug out from their PC each night? Does anyone has any ideas of what might be causing this situation? What does onstat -x show? This will detail the actual transaction. Ensure that all you distributed transactions use the TCP connections from server to server. onmode -H 0x83dceef8 might have worked in this situation. onmode -H <address> forget heuristically completed transaction These suggestions are, I think, reasonable. Heuristic rollbacks are inherently unsatisfactory, but until you know why the XA coordinator is not around, it may be your best workaround - more satisfactory than having Informix support come in to do that. Although the errors mention two phase (distributed) transactions, unless there is another IDS server that could also be in use - and it would be having recovery problems too, and it would be the coordinator system for the transactions - then the problem is that the XA coordinator is dying and not reappearing in a timely manner. And, as I suggested, that sounds like a PC using MTS that is not shutting up shop properly - nor restarting reliably. Since the problems happened in the evening (quarter to six; eight o'clock0), this is a semi-plausible hypothesis. I wonder; could the XA coordinator be on a DHCP host, which doesn't get the same IP address when it is restarted? That could screw things up totally. I don't know whether IDS would allow a different IP address to identify the original GTRID and close the transaction, or whether IDS would say "well, that GTRID was not originated by your (new DHCP) IP address, so I can say I know nothing about the XA TX; we can presume it was aborted", while still waiting for the original IP address to ask about the GTRID - or say that it was rolled back. -- Jonathan Leffler #include <disclaimer.h Email: Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/ |
sending to informix-list
#2
| |||
| |||
|
#3
| |||||
| |||||
|
|
Do I just ask really stupid questions? |
Quote:
I never get any responses...you can be brutally honest...doubt I know where you live.  |
Quote:
|
-----Original Message----- From: Gentsch, Sam Sent: Tuesday, May 18, 2004 9:16 AM To: informix-list (AT) iiug (DOT) org Subject: Remote LONGTX with no userthread in 9.30 UC6 W4 ...forgive the long copy and double post on ids (was having problems posting here), but it has been a while, I'll post at the top to save you time... What is the difference in the following commands? onmode -H <address> forget heuristically completed transaction onmode -Z <address> heuristically complete specified transaction The admin guide says the -Z places an ENDTRANS (after a ROLLBACK) into the logical log, but what does the -H do? |
Quote:
|
Would the -Z have also worked in the scenario of the following post? (I recently had the same situation, and the -H did the trick. I just found the section in the Admin Guide -The Heuristic Rollback Scenario this and am wondering if I did the right thing and what to do next time!). |
deliberate. I couldn't find it in the OnLine 5.2x manual either.
However, there was some information in there (chapter 11) about
completely forgetting about a TX - over and above what was implied by
-Z. So, I think -H is undocumented because you don't want to use it.
It's basically a more ruthless version of -Z. Someone else might
contradict me - they might be right to do so.
Quote:
|
Thanks! Sam Gentsch sending to informix-list |
--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler (AT) earthlink (DOT) net, jleffler (AT) us (DOT) ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
#4
| |||
| |||
|
|
Do I just ask really stupid questions? |
Quote:
|
I never get any responses...you can be brutally honest...doubt I know where you live. |
You won't be able to say that again!
sending to informix-list
|
« Previous Thread
|
Next Thread »
| Thread Tools | Search this Thread |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.