XA question

We are seeing global transactions that are started by our Glassfish server (by way of the Informix XA JDBC driver version 3.70.JC4 under the control of the Glassfish XA transaction monitor) that do not die. That is, even though ostensibly Glassfish is telling Informix that a given XA transaction is either committed or rolled back, the transaction ID persists in Informix. From the reading I've been able to do in the infocenter, this means (I take it) that Informix believes that there is an outstanding XA transaction that is still running (i.e. it hasn't been told to abort or proceed yet). Of course Glassfishbelieves that everything is in order, and the (XA transactional) EJB in question completes normally as though everything is hunky dory. I'm also engaging the Glassfish community, but is this a known problem with some part of the Informix linkage? Assuming for the moment that the Glassfish transaction monitor is a good XA citizen and is sending all the appropriate commit or rollback statements (since our application does not issue them directly), is there some setting in perhaps the Informix JDBC driver that I should be turning on to make sure that these instructions are making it all the way to the Informix instance? I apologize (as always, again, constantly) for my ignorance but could not find anything in the infocenter to help me out with this. Best, Laird -- http://about.me/lairdnelson --0016e6d58f00ba957204c0407456

On 17.05.12 21:29, Laird Nelson wrote: > We are seeing global transactions that are started by our Glassfish server > (by way of the Informix XA JDBC driver version 3.70.JC4 under the control > of the Glassfish XA transaction monitor) that do not die. > > That is, even though ostensibly Glassfish is telling Informix that a given > XA transaction is either committed or rolled back, the transaction ID > persists in Informix. From the reading I've been able to do in the > infocenter, this means (I take it) that Informix believes that there is an > outstanding XA transaction that is still running (i.e. it hasn't been told > to abort or proceed yet). Of course Glassfishbelieves that everything is > in order, and the (XA transactional) EJB in question completes normally as > though everything is hunky dory. > > I'm also engaging the Glassfish community, but is this a known problem with > some part of the Informix linkage? Assuming for the moment that the > Glassfish transaction monitor is a good XA citizen and is sending all the > appropriate commit or rollback statements (since our application does not > issue them directly), is there some setting in perhaps the Informix JDBC > driver that I should be turning on to make sure that these instructions are > making it all the way to the Informix instance? > > I apologize (as always, again, constantly) for my ignorance but could not > find anything in the infocenter to help me out with this. > > Best, > Laird > What's the output of "onstat -G"? It will also tell us the server version you're using.

On Thu, May 17, 2012 at 3:42 PM, Frank Langelage <frank@lafr.de> wrote: > What's the output of "onstat -G"? > It will also tell us the server version you're using. > I will have our db guy provide this. The server version is 11.50.FC8, according to what is reported back to my JDBC driver. Best, Laird -- http://about.me/lairdnelson --f46d04374a0fb00fe804c040b086

Hello. On your Informix engine, ensure that you´re using HETERO_COMMIT=1 (default is zero). That should fix your issue, considering (of course) you are acessing logged databases. Regards. Alexandre Marini IBM Informix Certified Professional v10 / v11.50 / v11.70 IBM Information Management Informix Technical Professional IBM Infosphere DataStage Technical Professional Database Administrator > To: ids@iiug.org > From: ljnelson@gmail.com > Subject: Re: XA question [27165] > Date: Thu, 17 May 2012 15:46:25 -0400 > > On Thu, May 17, 2012 at 3:42 PM, Frank Langelage <frank@lafr.de> wrote: > > > What's the output of "onstat -G"? > > It will also tell us the server version you're using. > > > > I will have our db guy provide this. The server version is 11.50.FC8, > according to what is reported back to my JDBC driver. > > Best, > Laird > > -- > http://about.me/lairdnelson > > --f46d04374a0fb00fe804c040b086 > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

As Frank says onstat -G will help you to follow XA transactions in the DB server. Using XA transactions is not the easiest thing, there is a number of things that has to work correctly on the application server side, a number of things in the JDBC driver and in the database. We have used Weblogic as application server with Informix for about 10 years now, it works but we have had to do some work in order to get there. From what you are describing it sounds like the TM (Glassfish JTA) does not send all XA commands it is supposed to do in order to finish the transaction. I do not know Glassfish but in Weblogic there is a number of settings in order to get it to work with Informix. There are some settings in Informix that you can try in order to solve XA issues, see http://www.google.se/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CFkQFjAB&url= http%3A%2F%2Fwww.iiug.org%2Fresources%2Farticles%2FXA_on_IDS_WebSphere.doc&ei=BF -1T66rCOjP4QSE-bC9Dg&usg=AFQjCNFl26XqKaKg-8UP57-AaAo0RKvNxg&sig2=oUET35-J51pl9es q4ofFeg Ulf

Hi, we have had some experiments with XA Datasources running with JBoss AS and encountered different behaviour depending on the client JDBC settings. We found out (back in 2005 I think, working with IDS 10.0 and JBoss 4, but parameters are still the same now, using IDS11.70), that the following parameters needed to be set explicitely: <xa-datasource-property name="IfxIFX_XASPEC">y</xa-datasource-property>^M <xa-datasource-property name="IfxIFX_XASTDCOMPLIANCE_XAEND">1</xa-datasource-property> This was steering the behaviour of the XA transaction. Maybe in glassfish, there is the same need when working with XA transactions and IDS. HETERO_COMMIT is not set in our environment. I think it is needed only if you have NON-Informix Datasources in a transaction together with Informix. We have also done this (Oracle and IDS working together, without using hetero_commit), but only in a test env. So no real productive info. We only sometimes have a problem when a JBoss Instance is stuck for some reason (Heap problem, endless loop, IP connection with no accuracte timeout within a XA transaction). Then it occurs that XA transactions are in IDS, while the JBoss instance is already terminated (killed). These transactions can only be killed with a trick (java program to attach to the transaction via JDBC and send a termination command). Good luck, Marcus ----- Ursprüngliche Mail ----- Von: "Laird Nelson" <ljnelson@gmail.com> An: ids@iiug.org Gesendet: Donnerstag, 17. Mai 2012 21:29:39 Betreff: XA question [27163] We are seeing global transactions that are started by our Glassfish server (by way of the Informix XA JDBC driver version 3.70.JC4 under the control of the Glassfish XA transaction monitor) that do not die. That is, even though ostensibly Glassfish is telling Informix that a given XA transaction is either committed or rolled back, the transaction ID persists in Informix. From the reading I've been able to do in the infocenter, this means (I take it) that Informix believes that there is an outstanding XA transaction that is still running (i.e. it hasn't been told to abort or proceed yet). Of course Glassfishbelieves that everything is in order, and the (XA transactional) EJB in question completes normally as though everything is hunky dory. I'm also engaging the Glassfish community, but is this a known problem with some part of the Informix linkage? Assuming for the moment that the Glassfish transaction monitor is a good XA citizen and is sending all the appropriate commit or rollback statements (since our application does not issue them directly), is there some setting in perhaps the Informix JDBC driver that I should be turning on to make sure that these instructions are making it all the way to the Informix instance? I apologize (as always, again, constantly) for my ignorance but could not find anything in the infocenter to help me out with this. Best, Laird -- http://about.me/lairdnelson --0016e6d58f00ba957204c0407456 ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.