how to terminate global transactions?
Frank Langelage
locks. See onstat -G and onstat -x output below.
How can I get rid of them?
Also after a server reboot they are still there.
onmode -Z <address> or onmode -H <address> do not work (see below).
IBM Informix Dynamic Server Version 11.50.UC7IE on Solaris SPARC 10.
Global Transaction Identifiers
address flags isol timeout fID gtl bql data
56656bd8 -LX-G LC 0 131075 30 28
312D2D35336530656466663A613139383A34633139336231393A373461652D35336530656466663A613139383A34633139336231393A37346233
56656e28 -LX-G LC 0 131075 30 28
312D2D35336530656466663A613139383A34633139336231393A373463312D35336530656466663A613139383A34633139336231393A37346336
2 active, 128 total
Transactions
est.
address flags userthread locks begin_logpos current logpos
isol rb_time retrys coord
56655018 A---- 56623018 0 - -
COMMIT - 0
56655268 A---- 56623638 0 - -
COMMIT - 0
566554b8 A---- 56623c58 0 - -
COMMIT - 0
56655708 A---- 56624278 0 - -
COMMIT - 0
56655958 A---- 56624898 0 - -
COMMIT - 0
56655ba8 A---- 56624eb8 0 - -
COMMIT - 0
56655df8 A---- 566254d8 0 - -
COMMIT - 0
56656048 A---- 56625af8 0 - -
COMMIT - 0
56656298 A---- 56626118 0 - -
COMMIT - 0
566564e8 A---- 56626738 0 - -
COMMIT - 0
56656738 A---- 56626d58 0 - -
COMMIT - 0
56656988 A---- 56627378 0 - -
COMMIT - 0
56656bd8 -LX-G 0 2 logid 303 303:0x64b2622c
COMMIT 2:58 0
56656e28 -LX-G 0 2 logid 303 303:0x64b2922c
COMMIT 2:58 0
56657078 A---- 56627fb8 0 - -
COMMIT - 0
566572c8 A---- 56627998 0 - -
COMMIT - 0
56657e58 A---- 56629218 0 - -
COMMIT - 0
17 active, 128 total, 28 maximum concurrent
> onmode -Z 1449487912
onmode: Cannot kill transaction 0x56656e28.
Only I-STAR subordinates that are PREPARE'd or HEURISTICally ABORT'd
may be heuristically completed.
> onmode -H 1449487912
onmode -H may only be used to kill heuristically completed transactions.
Davorin Kremenjas
> On my Informix instance I have two global transactions holding some
> locks. See onstat -G and onstat -x output below.
> How can I get rid of them?
> Also after a server reboot they are still there.
> onmode -Z <address> or onmode -H <address> do not work (see below).
Hi Frank,
onmode will not work AFAIK. These global transactions were started by
a "distributed" application, (transaction manager) and Informix is
only a participant in XA transaction. Transaction manager (a wild
guess: Java app server?) needs to send either a commit or rollback now
to this participant.
Did your application crash? If it implements TP/XA transaction
management fully it should have means of finishing transactions in
progress after it comes back online.
If nothing works, call IBM Tech Support, they have a tool which will
clean this up for you.
HTH
Davorin
Frank Langelage
Thanks for your help.
Yes, it was a Java Application Server using distributed transactions and
this ran out of PermGen space so I had to kill -9 it.
Today I cannot figure out anymore why the transaction was not rolled back.
The instance is used for testing and developing and I do not have a
support contract for it (Innovator-C Edition).
Would dropping and recreating the database erase this open transaction?
Or do I have to initialize the whole instance?
Regards, Frank
Davorin Kremenjas
> Yes, it was a Java Application Server using distributed transactions and
> this ran out of PermGen space so I had to kill -9 it.
> Today I cannot figure out anymore why the transaction was not rolled back.
> The instance is used for testing and developing and I do not have a
> support contract for it (Innovator-C Edition).
> Would dropping and recreating the database erase this open transaction?
> Or do I have to initialize the whole instance?
The transaction was not rolled back because Informix never got the
instruction to either roll it back or commit from your Java app
server. This is the correct behaviour accoring TP/XA specification.
Transaction managers should implement all the necessary logic to do
the rollback (or commit) after they come on-line after the crash. I
know JBoss does it.
The entry of this non-finished transaction is as always written to
your logical logs so dropping the database will not help (I'm not even
sure if you can drop it at all in the current state, with open
transaction on it, but you can always try).
Reinitialising the instance from scratch will certainly do the
trick...
HTH
Davorin
Ulf
Try onmode -l until you have forced a long transaction, this usually
help us. We have requested a way to get rid of these, but it seems
that the view of IBM that the TM should handle this i all cases.
Problem is that the TM fails sometimes, and then you are stuck.
Regards
Ulf
Frank Langelage
Today, the transactions were rolled back by the server:
23:42:09 Aborting Long Transaction: tx: 0x56656bd8 no user info due to
XA or distributed (2-phase commit) transaction
23:42:09 Aborting Long Transaction: tx: 0x56656e28 no user info due to
XA or distributed (2-phase commit) transaction
23:42:13 Checkpoint Completed: duration was 4 seconds.
23:42:13 Thu Jul 1 - loguniq 306, logpos 0x3fff33b4, timestamp:
0xdedfaa19 Interval: 5616
23:42:13 Maximum server connections 15
23:42:13 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns
blocked 1, Plog used 83432, Llog used 182271
23:42:13 Session completed abnormally. Rolling back tx id 24, flags
0x108463b
23:42:13 Session completed abnormally. Rolling back tx id 32, flags
0x108463b
23:42:13 Long Transaction 0x56656e28 Aborted. Rollback Duration: 0 Seconds
23:42:14 Long Transaction 0x56656bd8 Aborted. Rollback Duration: 0 Seconds
joseg...@gmail.com
Pankrich k
For v7.3 if i rember well, it needs.
Pankrich Khanthasa-ard
By iPhone
> On 23 ม.ค. 2557, at 03:09, joseg...@gmail.com wrote:
>
> Hi, the IBM tool to eliminate XA locks is called XAComplete. It requires that you attend a support engineer who knows and knows how to use.
> Informix-list mailing list
> Inform...@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list