XA Transaction blocking server

Hi, we encountered a problem on our development server, which lead to a blocking IDS 10.0 instance: We made a XA-Transaction containing two datasources on different IDS instances. For some reason, the transaction was aborted: 18:48:35 Aborting Long Transaction: tx 0x10f151398 no user info due to XA or di stributed (2-phase commit) transaction 18:48:35 Session completed abnormally. Rolling back tx id 67, flags 0x108463b Since this time, the server was blocked with LONGTX. "Blocking on XA transaction, tx 0x10f147078, till it is cleaned up." I found out that the transaction is active on both instances (onstat -x shows them) and was able to kill a part of it with onmode -H (thanks to Jonathan Lefflers email some years ago). But the transaction seems to live somewhere: Here is the onstat -x output from instance 1: 10b32edc0 --X-G 0 0 1428 1428 0xde048 COMMIT 0 instance2: 10e22edc0 --X-G 0 0 232 232 0x394048 COMMIT 0 Although the blocking is gone, I have no idea how to get rid of these fragments. onmode -H cannot remove these (seem to be of the wrong type ?). The only solution I can think of is dbexport all databases and reinstall. Our system is: Solaris 10(Sparc), IDS 10.00.FC4 Any ideas ? Thanks, Marcus

Now, the blocking is again active. DB is not responding any more to normal transactions. Onmode -l does not switch the log in this situation. Other ideas ? Marcus -----Original Message----- From: Ulf Åkerberg [mailto:ulf.akerberg@migrationsverket.se] Sent: Tuesday, September 05, 2006 11:22 AM To: marcus.haarmann@midoco.de Subject: Sv: XA Transaction blocking server [7422] Try to force a long transaction by doing onmode -l until you get it. That's the way we used to do in 7.31 at least Med vänlig hälsning /Regards Ulf Åkerberg Migrationsverket / Swedish Migration Board IT-enheten/ IT Department SE-601 70 NORRKÖPING Telefon 011 15 66 06 / +46 11 15 66 06 Mobil 0734 444 176 / +46 734 444 176 ulf.akerberg@migrationsverket.se >>> marcus.haarmann@midoco.de 2006-09-05 10:35 >>> Hi, we encountered a problem on our development server, which lead to a blocking IDS 10.0 instance: We made a XA-Transaction containing two datasources on different IDS instances. For some reason, the transaction was aborted: 18:48:35 Aborting Long Transaction: tx 0x10f151398 no user info due to XA or di stributed (2-phase commit) transaction 18:48:35 Session completed abnormally. Rolling back tx id 67, flags 0x108463b Since this time, the server was blocked with LONGTX. "Blocking on XA transaction, tx 0x10f147078, till it is cleaned up." I found out that the transaction is active on both instances (onstat -x shows them) and was able to kill a part of it with onmode -H (thanks to Jonathan Lefflers email some years ago). But the transaction seems to live somewhere: Here is the onstat -x output from instance 1: 10b32edc0 --X-G 0 0 1428 1428 0xde048 COMMIT 0 instance2: 10e22edc0 --X-G 0 0 232 232 0x394048 COMMIT 0 Although the blocking is gone, I have no idea how to get rid of these fragments. onmode -H cannot remove these (seem to be of the wrong type ?). The only solution I can think of is dbexport all databases and reinstall. Our system is: Solaris 10(Sparc), IDS 10.00.FC4 Any ideas ? Thanks, Marcus **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum.

Sorry, I misunderstood your comment. So the trick is: In case the server is blocking: do onmode -H for the transaction (found in onstat -x).In case there are transaction parts which are not deletable (which will not block immediately), force a log change with onmode -l until the server blocks and kill them with onmode -H. Now the transactions are gone, thanks for the quick answer. Marcus -----Original Message----- From: Ulf Åkerberg [mailto:ulf.akerberg@migrationsverket.se] Sent: Tuesday, September 05, 2006 11:22 AM To: marcus.haarmann@midoco.de Subject: Sv: XA Transaction blocking server [7422] Try to force a long transaction by doing onmode -l until you get it. That's the way we used to do in 7.31 at least Med vänlig hälsning /Regards Ulf Åkerberg Migrationsverket / Swedish Migration Board IT-enheten/ IT Department SE-601 70 NORRKÖPING Telefon 011 15 66 06 / +46 11 15 66 06 Mobil 0734 444 176 / +46 734 444 176 ulf.akerberg@migrationsverket.se >>> marcus.haarmann@midoco.de 2006-09-05 10:35 >>> Hi, we encountered a problem on our development server, which lead to a blocking IDS 10.0 instance: We made a XA-Transaction containing two datasources on different IDS instances. For some reason, the transaction was aborted: 18:48:35 Aborting Long Transaction: tx 0x10f151398 no user info due to XA or di stributed (2-phase commit) transaction 18:48:35 Session completed abnormally. Rolling back tx id 67, flags 0x108463b Since this time, the server was blocked with LONGTX. "Blocking on XA transaction, tx 0x10f147078, till it is cleaned up." I found out that the transaction is active on both instances (onstat -x shows them) and was able to kill a part of it with onmode -H (thanks to Jonathan Lefflers email some years ago). But the transaction seems to live somewhere: Here is the onstat -x output from instance 1: 10b32edc0 --X-G 0 0 1428 1428 0xde048 COMMIT 0 instance2: 10e22edc0 --X-G 0 0 232 232 0x394048 COMMIT 0 Although the blocking is gone, I have no idea how to get rid of these fragments. onmode -H cannot remove these (seem to be of the wrong type ?). The only solution I can think of is dbexport all databases and reinstall. Our system is: Solaris 10(Sparc), IDS 10.00.FC4 Any ideas ? Thanks, Marcus **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum.

Correct ! Med vänlig hälsning /Regards Ulf Åkerberg Migrationsverket / Swedish Migration Board IT-enheten/ IT Department SE-601 70 NORRKÖPING Telefon 011 15 66 06 / +46 11 15 66 06 Mobil 0734 444 176 / +46 734 444 176 ulf.akerberg@migrationsverket.se >>> marcus.haarmann@midoco.de 2006-09-05 11:43 >>> Sorry, I misunderstood your comment. So the trick is: In case the server is blocking: do onmode -H for the transaction (found in onstat -x).In case there are transaction parts which are not deletable (which will not block immediately), force a log change with onmode -l until the server blocks and kill them with onmode -H. Now the transactions are gone, thanks for the quick answer. Marcus -----Original Message----- From: Ulf Åkerberg [mailto:ulf.akerberg@migrationsverket.se] Sent: Tuesday, September 05, 2006 11:22 AM To: marcus.haarmann@midoco.de Subject: Sv: XA Transaction blocking server [7422] Try to force a long transaction by doing onmode -l until you get it. That's the way we used to do in 7.31 at least Med vänlig hälsning /Regards Ulf Åkerberg Migrationsverket / Swedish Migration Board IT-enheten/ IT Department SE-601 70 NORRKÖPING Telefon 011 15 66 06 / +46 11 15 66 06 Mobil 0734 444 176 / +46 734 444 176 ulf.akerberg@migrationsverket.se >>> marcus.haarmann@midoco.de 2006-09-05 10:35 >>> Hi, we encountered a problem on our development server, which lead to a blocking IDS 10.0 instance: We made a XA-Transaction containing two datasources on different IDS instances. For some reason, the transaction was aborted: 18:48:35 Aborting Long Transaction: tx 0x10f151398 no user info due to XA or di stributed (2-phase commit) transaction 18:48:35 Session completed abnormally. Rolling back tx id 67, flags 0x108463b Since this time, the server was blocked with LONGTX. "Blocking on XA transaction, tx 0x10f147078, till it is cleaned up." I found out that the transaction is active on both instances (onstat -x shows them) and was able to kill a part of it with onmode -H (thanks to Jonathan Lefflers email some years ago). But the transaction seems to live somewhere: Here is the onstat -x output from instance 1: 10b32edc0 --X-G 0 0 1428 1428 0xde048 COMMIT 0 instance2: 10e22edc0 --X-G 0 0 232 232 0x394048 COMMIT 0 Although the blocking is gone, I have no idea how to get rid of these fragments. onmode -H cannot remove these (seem to be of the wrong type ?). The only solution I can think of is dbexport all databases and reinstall. Our system is: Solaris 10(Sparc), IDS 10.00.FC4 Any ideas ? Thanks, Marcus **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.