[JBoss-dev] [ jboss-Bugs-820711 ] Problem with XA and DB2 for iSeries XA drivers
Bugs item #820711, was opened at 2003-10-09 16:01 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=820711group_id=22866 Category: JBossCX Group: v3.0 Rabbit Hole Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Eduard Letifov (techtime) Assigned to: Adrian Brock (ejort) Summary: Problem with XA and DB2 for iSeries XA drivers Initial Comment: This problem seem to be very simular to the one reported in 585632. We have several EJB beans (Session and Entity) participating in one transaction started by MDB that also uses XA JMS in the end. The first call that involves database goes fine. From trace logs I see that XAResource gets enlisted and delisted. Resource state is set to RS_ENDED. As soon as the second method is called (and connection is requested) TxCapsule tries to enlist and start the same resource. This caused an XAException (XAER_INVAL) with DB2 for iSeries (AS400) XA toolbox (thin) drivers. I was able to overcome this by specifying the same (IsSameRMOverrideValue=false) flag as for Oracle XA datasource. In this case (as I beleive it was intended) the resource is started with a new XA branch (JBoss_3_0_8, TxCapsule.java, lines: 702-737) Unfortunately it is also marked as being one from a new RM (line 737). Thus, when transaction is finished and TxCapsule starts preparing XAResources the same RM check does not work (line 1635) and the resource gets called multiple times. The first call returns some valid READ_ONLY result, but the second one fails with XAER_PROTO. As I figured out unlike Oracle, DB2 wants only one prepare and one commit per RM. I was able to overcome this by performing these patches: - when the resource is started with the new branch the idx of the originally found resource is recorded additionally. - if the XAException with code XAER_PROTO is thrown in the prepare stage and this originally found index is not (- 1) it is ignored and the prepare state is assumed to be the same as for originally found (and already prepared) resource - if the XAException with code XAER_PROTO is thrown in the commit stage and the originally found index is not (- 1) it is ignored. It seem to work both for DB2 and Oracle. It does produce multiple calls to resources on prepare and commit that for DB2 fail all except the first one. I understand that this impacts perfomance, but the other option. My operating system is WinXP, JDK1.3.1_06. I have looked in Jboss 3.2.2 source and I see that basically the code is the same. Please confirm that this is in fact the way to solve the problem. -- Comment By: Adrian Brock (ejort) Date: 2004-05-26 00:36 Message: Logged In: YES user_id=9459 It is unlikely there will ever be a JBoss-3.0.9 release. -- Comment By: Adrian Brock (ejort) Date: 2003-10-10 12:46 Message: Logged In: YES user_id=9459 Sorry, I must have been looking at the wrong source tree. You are correct that attribute is not in 3.0 The only sensible solution would be to backport the 3.2 jca implementation to 3.0 but I don't think that is straight forward. I am unlikely to do it in the near future, I'm currently working on the 3.2.2 final release. Maybe you can look at the TxConnectionManager in 3.2 and apply the processing yourself to the XATxConnectionManager in 3.0? Regards, Adrian -- Comment By: Eduard Letifov (techtime) Date: 2003-10-10 12:30 Message: Logged In: YES user_id=438410 Adrian, I have a problem. A problem in Jboss 3.0.8. A release. Not release candidate or beta, etc. I've spent 2 days on it before I turned to you. I did what I can do. I identified the problem. I tried to overcome it with a patch. Since the behaviour was changed in 3.2.2 I guess something was wrong with it, heh? Not a bug, rejected, fixed in 3.2, use 3.2 is definately a solution, but maybe not the only one? As I understand in order for what you are suggesting to work the underlying MBean has to have this attribute and corresponding setters/getters. In my 3.0.8 source it doesn't. Neither does the implementation. Obviously I am getting org.jboss.deployment.DeploymentException: No Attribute found with name: TrackConnectionByTx exception? would you consider this a bug? Ed -- Comment By: Adrian Brock (ejort) Date: 2003-10-10 10:46 Message: Logged In: YES user_id=9459 Please use the jboss-user mailing list or forums for help. Not bug reports. You would configure it on the connection manager as I said before. e.g. mbean code=org.jboss.resource.connectionmanager.XATxConnectionManager name=jboss.jca:service=XATxCM,name=XAOracleDS attribute
[JBoss-dev] [ jboss-Bugs-820711 ] Problem with XA and DB2 for iSeries XA drivers
Bugs item #820711, was opened at 2003-10-09 20:01 Message generated for change (Comment added) made by techtime You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=820711group_id=22866 Category: JBossTX Group: v3.0 Rabbit Hole Status: Closed Resolution: Rejected Priority: 5 Submitted By: Eduard Letifov (techtime) Assigned to: Adrian Brock (ejort) Summary: Problem with XA and DB2 for iSeries XA drivers Initial Comment: This problem seem to be very simular to the one reported in 585632. We have several EJB beans (Session and Entity) participating in one transaction started by MDB that also uses XA JMS in the end. The first call that involves database goes fine. From trace logs I see that XAResource gets enlisted and delisted. Resource state is set to RS_ENDED. As soon as the second method is called (and connection is requested) TxCapsule tries to enlist and start the same resource. This caused an XAException (XAER_INVAL) with DB2 for iSeries (AS400) XA toolbox (thin) drivers. I was able to overcome this by specifying the same (IsSameRMOverrideValue=false) flag as for Oracle XA datasource. In this case (as I beleive it was intended) the resource is started with a new XA branch (JBoss_3_0_8, TxCapsule.java, lines: 702-737) Unfortunately it is also marked as being one from a new RM (line 737). Thus, when transaction is finished and TxCapsule starts preparing XAResources the same RM check does not work (line 1635) and the resource gets called multiple times. The first call returns some valid READ_ONLY result, but the second one fails with XAER_PROTO. As I figured out unlike Oracle, DB2 wants only one prepare and one commit per RM. I was able to overcome this by performing these patches: - when the resource is started with the new branch the idx of the originally found resource is recorded additionally. - if the XAException with code XAER_PROTO is thrown in the prepare stage and this originally found index is not (- 1) it is ignored and the prepare state is assumed to be the same as for originally found (and already prepared) resource - if the XAException with code XAER_PROTO is thrown in the commit stage and the originally found index is not (- 1) it is ignored. It seem to work both for DB2 and Oracle. It does produce multiple calls to resources on prepare and commit that for DB2 fail all except the first one. I understand that this impacts perfomance, but the other option. My operating system is WinXP, JDK1.3.1_06. I have looked in Jboss 3.2.2 source and I see that basically the code is the same. Please confirm that this is in fact the way to solve the problem. -- Comment By: Eduard Letifov (techtime) Date: 2003-10-10 11:21 Message: Logged In: YES user_id=438410 I have tested it with 3.2.2 running on Windows connecting to DB2 running V5R2 AS400. Both parameters (trackConnnection and RMOverride) had to be set to true and false respectively. Good news for the future. I wasn't able to find this attribute in 3.0.8 source though, can you help me on that? Ed. -- Comment By: Adrian Brock (ejort) Date: 2003-10-09 21:07 Message: Logged In: YES user_id=9459 Minerva hasn't been in jboss for a while, 2.4 I think The transaction implementation is different between 3.0 and 3.2, I can only suggest testing it. TrackConnectionByTx is available in 3.0 as an attribute on the XATXConnectionManager (I'm not sure when it was added, 3.0.7 I think). Regards, Adrian -- Comment By: Eduard Letifov (techtime) Date: 2003-10-09 20:57 Message: Logged In: YES user_id=438410 Adrian, Yes, you are correct in regards to 3.2. I meant the enlist part. I will try the test with 3.2 right now. Meanwhile a question: is it possible to comment out the same lines in 3.0.8 or does it still have the 'Minerva crap'? I don't think I will be able to present our customers with 3.2 gift for their AS400. I wish I wasn't anywhere near AS400 either Ed. -- Comment By: Adrian Brock (ejort) Date: 2003-10-09 20:28 Message: Logged In: YES user_id=9459 The code is not the same in the 3.2 branch. Look at endResources in TransactionImpl.java and the comment about minerva. There is also the option to track-connection-by-tx where you can force a resource to remain in the enlisted state until the transaction completes. Please try your test with 3.2 without modification. If this doesn't work, please provide information about the problem you are seeing and enable TRACE logging for org.jboss.tm and org.jboss.resource in conf/log4j.xml The output will go into log/server.log I don't personally have an AS/400 :-) I do have a copy of Oracle if you want to provide a testcase.
[JBoss-dev] [ jboss-Bugs-820711 ] Problem with XA and DB2 for iSeries XA drivers
Bugs item #820711, was opened at 2003-10-09 16:01 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=820711group_id=22866 Category: JBossTX Group: v3.0 Rabbit Hole Status: Closed Resolution: Rejected Priority: 5 Submitted By: Eduard Letifov (techtime) Assigned to: Adrian Brock (ejort) Summary: Problem with XA and DB2 for iSeries XA drivers Initial Comment: This problem seem to be very simular to the one reported in 585632. We have several EJB beans (Session and Entity) participating in one transaction started by MDB that also uses XA JMS in the end. The first call that involves database goes fine. From trace logs I see that XAResource gets enlisted and delisted. Resource state is set to RS_ENDED. As soon as the second method is called (and connection is requested) TxCapsule tries to enlist and start the same resource. This caused an XAException (XAER_INVAL) with DB2 for iSeries (AS400) XA toolbox (thin) drivers. I was able to overcome this by specifying the same (IsSameRMOverrideValue=false) flag as for Oracle XA datasource. In this case (as I beleive it was intended) the resource is started with a new XA branch (JBoss_3_0_8, TxCapsule.java, lines: 702-737) Unfortunately it is also marked as being one from a new RM (line 737). Thus, when transaction is finished and TxCapsule starts preparing XAResources the same RM check does not work (line 1635) and the resource gets called multiple times. The first call returns some valid READ_ONLY result, but the second one fails with XAER_PROTO. As I figured out unlike Oracle, DB2 wants only one prepare and one commit per RM. I was able to overcome this by performing these patches: - when the resource is started with the new branch the idx of the originally found resource is recorded additionally. - if the XAException with code XAER_PROTO is thrown in the prepare stage and this originally found index is not (- 1) it is ignored and the prepare state is assumed to be the same as for originally found (and already prepared) resource - if the XAException with code XAER_PROTO is thrown in the commit stage and the originally found index is not (- 1) it is ignored. It seem to work both for DB2 and Oracle. It does produce multiple calls to resources on prepare and commit that for DB2 fail all except the first one. I understand that this impacts perfomance, but the other option. My operating system is WinXP, JDK1.3.1_06. I have looked in Jboss 3.2.2 source and I see that basically the code is the same. Please confirm that this is in fact the way to solve the problem. -- Comment By: Adrian Brock (ejort) Date: 2003-10-10 10:46 Message: Logged In: YES user_id=9459 Please use the jboss-user mailing list or forums for help. Not bug reports. You would configure it on the connection manager as I said before. e.g. mbean code=org.jboss.resource.connectionmanager.XATxConnectionManager name=jboss.jca:service=XATxCM,name=XAOracleDS attribute name=TrackConnectionByTxtrue/attribute depends optional-attribute-name=ManagedConnectionFactoryName Regards, Adrian -- Comment By: Eduard Letifov (techtime) Date: 2003-10-10 07:21 Message: Logged In: YES user_id=438410 I have tested it with 3.2.2 running on Windows connecting to DB2 running V5R2 AS400. Both parameters (trackConnnection and RMOverride) had to be set to true and false respectively. Good news for the future. I wasn't able to find this attribute in 3.0.8 source though, can you help me on that? Ed. -- Comment By: Adrian Brock (ejort) Date: 2003-10-09 17:07 Message: Logged In: YES user_id=9459 Minerva hasn't been in jboss for a while, 2.4 I think The transaction implementation is different between 3.0 and 3.2, I can only suggest testing it. TrackConnectionByTx is available in 3.0 as an attribute on the XATXConnectionManager (I'm not sure when it was added, 3.0.7 I think). Regards, Adrian -- Comment By: Eduard Letifov (techtime) Date: 2003-10-09 16:57 Message: Logged In: YES user_id=438410 Adrian, Yes, you are correct in regards to 3.2. I meant the enlist part. I will try the test with 3.2 right now. Meanwhile a question: is it possible to comment out the same lines in 3.0.8 or does it still have the 'Minerva crap'? I don't think I will be able to present our customers with 3.2 gift for their AS400. I wish I wasn't anywhere near AS400 either Ed. -- Comment By: Adrian Brock (ejort) Date: 2003-10-09 16:28 Message: Logged In: YES user_id=9459 The code is not the same in the 3.2 branch. Look at
[JBoss-dev] [ jboss-Bugs-820711 ] Problem with XA and DB2 for iSeries XA drivers
Bugs item #820711, was opened at 2003-10-09 20:01 Message generated for change (Comment added) made by techtime You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=820711group_id=22866 Category: JBossTX Group: v3.0 Rabbit Hole Status: Closed Resolution: Rejected Priority: 5 Submitted By: Eduard Letifov (techtime) Assigned to: Adrian Brock (ejort) Summary: Problem with XA and DB2 for iSeries XA drivers Initial Comment: This problem seem to be very simular to the one reported in 585632. We have several EJB beans (Session and Entity) participating in one transaction started by MDB that also uses XA JMS in the end. The first call that involves database goes fine. From trace logs I see that XAResource gets enlisted and delisted. Resource state is set to RS_ENDED. As soon as the second method is called (and connection is requested) TxCapsule tries to enlist and start the same resource. This caused an XAException (XAER_INVAL) with DB2 for iSeries (AS400) XA toolbox (thin) drivers. I was able to overcome this by specifying the same (IsSameRMOverrideValue=false) flag as for Oracle XA datasource. In this case (as I beleive it was intended) the resource is started with a new XA branch (JBoss_3_0_8, TxCapsule.java, lines: 702-737) Unfortunately it is also marked as being one from a new RM (line 737). Thus, when transaction is finished and TxCapsule starts preparing XAResources the same RM check does not work (line 1635) and the resource gets called multiple times. The first call returns some valid READ_ONLY result, but the second one fails with XAER_PROTO. As I figured out unlike Oracle, DB2 wants only one prepare and one commit per RM. I was able to overcome this by performing these patches: - when the resource is started with the new branch the idx of the originally found resource is recorded additionally. - if the XAException with code XAER_PROTO is thrown in the prepare stage and this originally found index is not (- 1) it is ignored and the prepare state is assumed to be the same as for originally found (and already prepared) resource - if the XAException with code XAER_PROTO is thrown in the commit stage and the originally found index is not (- 1) it is ignored. It seem to work both for DB2 and Oracle. It does produce multiple calls to resources on prepare and commit that for DB2 fail all except the first one. I understand that this impacts perfomance, but the other option. My operating system is WinXP, JDK1.3.1_06. I have looked in Jboss 3.2.2 source and I see that basically the code is the same. Please confirm that this is in fact the way to solve the problem. -- Comment By: Eduard Letifov (techtime) Date: 2003-10-10 16:30 Message: Logged In: YES user_id=438410 Adrian, I have a problem. A problem in Jboss 3.0.8. A release. Not release candidate or beta, etc. I've spent 2 days on it before I turned to you. I did what I can do. I identified the problem. I tried to overcome it with a patch. Since the behaviour was changed in 3.2.2 I guess something was wrong with it, heh? Not a bug, rejected, fixed in 3.2, use 3.2 is definately a solution, but maybe not the only one? As I understand in order for what you are suggesting to work the underlying MBean has to have this attribute and corresponding setters/getters. In my 3.0.8 source it doesn't. Neither does the implementation. Obviously I am getting org.jboss.deployment.DeploymentException: No Attribute found with name: TrackConnectionByTx exception? would you consider this a bug? Ed -- Comment By: Adrian Brock (ejort) Date: 2003-10-10 14:46 Message: Logged In: YES user_id=9459 Please use the jboss-user mailing list or forums for help. Not bug reports. You would configure it on the connection manager as I said before. e.g. mbean code=org.jboss.resource.connectionmanager.XATxConnectionManager name=jboss.jca:service=XATxCM,name=XAOracleDS attribute name=TrackConnectionByTxtrue/attribute depends optional-attribute-name=ManagedConnectionFactoryName Regards, Adrian -- Comment By: Eduard Letifov (techtime) Date: 2003-10-10 11:21 Message: Logged In: YES user_id=438410 I have tested it with 3.2.2 running on Windows connecting to DB2 running V5R2 AS400. Both parameters (trackConnnection and RMOverride) had to be set to true and false respectively. Good news for the future. I wasn't able to find this attribute in 3.0.8 source though, can you help me on that? Ed. -- Comment By: Adrian Brock (ejort) Date: 2003-10-09 21:07 Message: Logged In: YES user_id=9459 Minerva hasn't been in jboss for a while, 2.4 I think The transaction implementation is different
[JBoss-dev] [ jboss-Bugs-820711 ] Problem with XA and DB2 for iSeries XA drivers
Bugs item #820711, was opened at 2003-10-09 16:01 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=820711group_id=22866 Category: JBossTX Group: v3.0 Rabbit Hole Status: Open Resolution: Accepted Priority: 5 Submitted By: Eduard Letifov (techtime) Assigned to: Adrian Brock (ejort) Summary: Problem with XA and DB2 for iSeries XA drivers Initial Comment: This problem seem to be very simular to the one reported in 585632. We have several EJB beans (Session and Entity) participating in one transaction started by MDB that also uses XA JMS in the end. The first call that involves database goes fine. From trace logs I see that XAResource gets enlisted and delisted. Resource state is set to RS_ENDED. As soon as the second method is called (and connection is requested) TxCapsule tries to enlist and start the same resource. This caused an XAException (XAER_INVAL) with DB2 for iSeries (AS400) XA toolbox (thin) drivers. I was able to overcome this by specifying the same (IsSameRMOverrideValue=false) flag as for Oracle XA datasource. In this case (as I beleive it was intended) the resource is started with a new XA branch (JBoss_3_0_8, TxCapsule.java, lines: 702-737) Unfortunately it is also marked as being one from a new RM (line 737). Thus, when transaction is finished and TxCapsule starts preparing XAResources the same RM check does not work (line 1635) and the resource gets called multiple times. The first call returns some valid READ_ONLY result, but the second one fails with XAER_PROTO. As I figured out unlike Oracle, DB2 wants only one prepare and one commit per RM. I was able to overcome this by performing these patches: - when the resource is started with the new branch the idx of the originally found resource is recorded additionally. - if the XAException with code XAER_PROTO is thrown in the prepare stage and this originally found index is not (- 1) it is ignored and the prepare state is assumed to be the same as for originally found (and already prepared) resource - if the XAException with code XAER_PROTO is thrown in the commit stage and the originally found index is not (- 1) it is ignored. It seem to work both for DB2 and Oracle. It does produce multiple calls to resources on prepare and commit that for DB2 fail all except the first one. I understand that this impacts perfomance, but the other option. My operating system is WinXP, JDK1.3.1_06. I have looked in Jboss 3.2.2 source and I see that basically the code is the same. Please confirm that this is in fact the way to solve the problem. -- Comment By: Adrian Brock (ejort) Date: 2003-10-10 12:46 Message: Logged In: YES user_id=9459 Sorry, I must have been looking at the wrong source tree. You are correct that attribute is not in 3.0 The only sensible solution would be to backport the 3.2 jca implementation to 3.0 but I don't think that is straight forward. I am unlikely to do it in the near future, I'm currently working on the 3.2.2 final release. Maybe you can look at the TxConnectionManager in 3.2 and apply the processing yourself to the XATxConnectionManager in 3.0? Regards, Adrian -- Comment By: Eduard Letifov (techtime) Date: 2003-10-10 12:30 Message: Logged In: YES user_id=438410 Adrian, I have a problem. A problem in Jboss 3.0.8. A release. Not release candidate or beta, etc. I've spent 2 days on it before I turned to you. I did what I can do. I identified the problem. I tried to overcome it with a patch. Since the behaviour was changed in 3.2.2 I guess something was wrong with it, heh? Not a bug, rejected, fixed in 3.2, use 3.2 is definately a solution, but maybe not the only one? As I understand in order for what you are suggesting to work the underlying MBean has to have this attribute and corresponding setters/getters. In my 3.0.8 source it doesn't. Neither does the implementation. Obviously I am getting org.jboss.deployment.DeploymentException: No Attribute found with name: TrackConnectionByTx exception? would you consider this a bug? Ed -- Comment By: Adrian Brock (ejort) Date: 2003-10-10 10:46 Message: Logged In: YES user_id=9459 Please use the jboss-user mailing list or forums for help. Not bug reports. You would configure it on the connection manager as I said before. e.g. mbean code=org.jboss.resource.connectionmanager.XATxConnectionManager name=jboss.jca:service=XATxCM,name=XAOracleDS attribute name=TrackConnectionByTxtrue/attribute depends optional-attribute-name=ManagedConnectionFactoryName Regards, Adrian -- Comment By: Eduard Letifov (techtime) Date:
[JBoss-dev] [ jboss-Bugs-820711 ] Problem with XA and DB2 for iSeries XA drivers
Bugs item #820711, was opened at 2003-10-09 20:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=820711group_id=22866 Category: JBossTX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Eduard Letifov (techtime) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with XA and DB2 for iSeries XA drivers Initial Comment: This problem seem to be very simular to the one reported in 585632. We have several EJB beans (Session and Entity) participating in one transaction started by MDB that also uses XA JMS in the end. The first call that involves database goes fine. From trace logs I see that XAResource gets enlisted and delisted. Resource state is set to RS_ENDED. As soon as the second method is called (and connection is requested) TxCapsule tries to enlist and start the same resource. This caused an XAException (XAER_INVAL) with DB2 for iSeries (AS400) XA toolbox (thin) drivers. I was able to overcome this by specifying the same (IsSameRMOverrideValue=false) flag as for Oracle XA datasource. In this case (as I beleive it was intended) the resource is started with a new XA branch (JBoss_3_0_8, TxCapsule.java, lines: 702-737) Unfortunately it is also marked as being one from a new RM (line 737). Thus, when transaction is finished and TxCapsule starts preparing XAResources the same RM check does not work (line 1635) and the resource gets called multiple times. The first call returns some valid READ_ONLY result, but the second one fails with XAER_PROTO. As I figured out unlike Oracle, DB2 wants only one prepare and one commit per RM. I was able to overcome this by performing these patches: - when the resource is started with the new branch the idx of the originally found resource is recorded additionally. - if the XAException with code XAER_PROTO is thrown in the prepare stage and this originally found index is not (- 1) it is ignored and the prepare state is assumed to be the same as for originally found (and already prepared) resource - if the XAException with code XAER_PROTO is thrown in the commit stage and the originally found index is not (- 1) it is ignored. It seem to work both for DB2 and Oracle. It does produce multiple calls to resources on prepare and commit that for DB2 fail all except the first one. I understand that this impacts perfomance, but the other option. My operating system is WinXP, JDK1.3.1_06. I have looked in Jboss 3.2.2 source and I see that basically the code is the same. Please confirm that this is in fact the way to solve the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=820711group_id=22866 --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-820711 ] Problem with XA and DB2 for iSeries XA drivers
Bugs item #820711, was opened at 2003-10-09 16:01 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=820711group_id=22866 Category: JBossTX Group: v3.0 Rabbit Hole Status: Closed Resolution: Rejected Priority: 5 Submitted By: Eduard Letifov (techtime) Assigned to: Adrian Brock (ejort) Summary: Problem with XA and DB2 for iSeries XA drivers Initial Comment: This problem seem to be very simular to the one reported in 585632. We have several EJB beans (Session and Entity) participating in one transaction started by MDB that also uses XA JMS in the end. The first call that involves database goes fine. From trace logs I see that XAResource gets enlisted and delisted. Resource state is set to RS_ENDED. As soon as the second method is called (and connection is requested) TxCapsule tries to enlist and start the same resource. This caused an XAException (XAER_INVAL) with DB2 for iSeries (AS400) XA toolbox (thin) drivers. I was able to overcome this by specifying the same (IsSameRMOverrideValue=false) flag as for Oracle XA datasource. In this case (as I beleive it was intended) the resource is started with a new XA branch (JBoss_3_0_8, TxCapsule.java, lines: 702-737) Unfortunately it is also marked as being one from a new RM (line 737). Thus, when transaction is finished and TxCapsule starts preparing XAResources the same RM check does not work (line 1635) and the resource gets called multiple times. The first call returns some valid READ_ONLY result, but the second one fails with XAER_PROTO. As I figured out unlike Oracle, DB2 wants only one prepare and one commit per RM. I was able to overcome this by performing these patches: - when the resource is started with the new branch the idx of the originally found resource is recorded additionally. - if the XAException with code XAER_PROTO is thrown in the prepare stage and this originally found index is not (- 1) it is ignored and the prepare state is assumed to be the same as for originally found (and already prepared) resource - if the XAException with code XAER_PROTO is thrown in the commit stage and the originally found index is not (- 1) it is ignored. It seem to work both for DB2 and Oracle. It does produce multiple calls to resources on prepare and commit that for DB2 fail all except the first one. I understand that this impacts perfomance, but the other option. My operating system is WinXP, JDK1.3.1_06. I have looked in Jboss 3.2.2 source and I see that basically the code is the same. Please confirm that this is in fact the way to solve the problem. -- Comment By: Adrian Brock (ejort) Date: 2003-10-09 16:28 Message: Logged In: YES user_id=9459 The code is not the same in the 3.2 branch. Look at endResources in TransactionImpl.java and the comment about minerva. There is also the option to track-connection-by-tx where you can force a resource to remain in the enlisted state until the transaction completes. Please try your test with 3.2 without modification. If this doesn't work, please provide information about the problem you are seeing and enable TRACE logging for org.jboss.tm and org.jboss.resource in conf/log4j.xml The output will go into log/server.log I don't personally have an AS/400 :-) I do have a copy of Oracle if you want to provide a testcase. Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=820711group_id=22866 --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-820711 ] Problem with XA and DB2 for iSeries XA drivers
Bugs item #820711, was opened at 2003-10-09 20:01 Message generated for change (Comment added) made by techtime You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=820711group_id=22866 Category: JBossTX Group: v3.0 Rabbit Hole Status: Closed Resolution: Rejected Priority: 5 Submitted By: Eduard Letifov (techtime) Assigned to: Adrian Brock (ejort) Summary: Problem with XA and DB2 for iSeries XA drivers Initial Comment: This problem seem to be very simular to the one reported in 585632. We have several EJB beans (Session and Entity) participating in one transaction started by MDB that also uses XA JMS in the end. The first call that involves database goes fine. From trace logs I see that XAResource gets enlisted and delisted. Resource state is set to RS_ENDED. As soon as the second method is called (and connection is requested) TxCapsule tries to enlist and start the same resource. This caused an XAException (XAER_INVAL) with DB2 for iSeries (AS400) XA toolbox (thin) drivers. I was able to overcome this by specifying the same (IsSameRMOverrideValue=false) flag as for Oracle XA datasource. In this case (as I beleive it was intended) the resource is started with a new XA branch (JBoss_3_0_8, TxCapsule.java, lines: 702-737) Unfortunately it is also marked as being one from a new RM (line 737). Thus, when transaction is finished and TxCapsule starts preparing XAResources the same RM check does not work (line 1635) and the resource gets called multiple times. The first call returns some valid READ_ONLY result, but the second one fails with XAER_PROTO. As I figured out unlike Oracle, DB2 wants only one prepare and one commit per RM. I was able to overcome this by performing these patches: - when the resource is started with the new branch the idx of the originally found resource is recorded additionally. - if the XAException with code XAER_PROTO is thrown in the prepare stage and this originally found index is not (- 1) it is ignored and the prepare state is assumed to be the same as for originally found (and already prepared) resource - if the XAException with code XAER_PROTO is thrown in the commit stage and the originally found index is not (- 1) it is ignored. It seem to work both for DB2 and Oracle. It does produce multiple calls to resources on prepare and commit that for DB2 fail all except the first one. I understand that this impacts perfomance, but the other option. My operating system is WinXP, JDK1.3.1_06. I have looked in Jboss 3.2.2 source and I see that basically the code is the same. Please confirm that this is in fact the way to solve the problem. -- Comment By: Eduard Letifov (techtime) Date: 2003-10-09 20:57 Message: Logged In: YES user_id=438410 Adrian, Yes, you are correct in regards to 3.2. I meant the enlist part. I will try the test with 3.2 right now. Meanwhile a question: is it possible to comment out the same lines in 3.0.8 or does it still have the 'Minerva crap'? I don't think I will be able to present our customers with 3.2 gift for their AS400. I wish I wasn't anywhere near AS400 either Ed. -- Comment By: Adrian Brock (ejort) Date: 2003-10-09 20:28 Message: Logged In: YES user_id=9459 The code is not the same in the 3.2 branch. Look at endResources in TransactionImpl.java and the comment about minerva. There is also the option to track-connection-by-tx where you can force a resource to remain in the enlisted state until the transaction completes. Please try your test with 3.2 without modification. If this doesn't work, please provide information about the problem you are seeing and enable TRACE logging for org.jboss.tm and org.jboss.resource in conf/log4j.xml The output will go into log/server.log I don't personally have an AS/400 :-) I do have a copy of Oracle if you want to provide a testcase. Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=820711group_id=22866 --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-820711 ] Problem with XA and DB2 for iSeries XA drivers
Bugs item #820711, was opened at 2003-10-09 16:01 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=820711group_id=22866 Category: JBossTX Group: v3.0 Rabbit Hole Status: Closed Resolution: Rejected Priority: 5 Submitted By: Eduard Letifov (techtime) Assigned to: Adrian Brock (ejort) Summary: Problem with XA and DB2 for iSeries XA drivers Initial Comment: This problem seem to be very simular to the one reported in 585632. We have several EJB beans (Session and Entity) participating in one transaction started by MDB that also uses XA JMS in the end. The first call that involves database goes fine. From trace logs I see that XAResource gets enlisted and delisted. Resource state is set to RS_ENDED. As soon as the second method is called (and connection is requested) TxCapsule tries to enlist and start the same resource. This caused an XAException (XAER_INVAL) with DB2 for iSeries (AS400) XA toolbox (thin) drivers. I was able to overcome this by specifying the same (IsSameRMOverrideValue=false) flag as for Oracle XA datasource. In this case (as I beleive it was intended) the resource is started with a new XA branch (JBoss_3_0_8, TxCapsule.java, lines: 702-737) Unfortunately it is also marked as being one from a new RM (line 737). Thus, when transaction is finished and TxCapsule starts preparing XAResources the same RM check does not work (line 1635) and the resource gets called multiple times. The first call returns some valid READ_ONLY result, but the second one fails with XAER_PROTO. As I figured out unlike Oracle, DB2 wants only one prepare and one commit per RM. I was able to overcome this by performing these patches: - when the resource is started with the new branch the idx of the originally found resource is recorded additionally. - if the XAException with code XAER_PROTO is thrown in the prepare stage and this originally found index is not (- 1) it is ignored and the prepare state is assumed to be the same as for originally found (and already prepared) resource - if the XAException with code XAER_PROTO is thrown in the commit stage and the originally found index is not (- 1) it is ignored. It seem to work both for DB2 and Oracle. It does produce multiple calls to resources on prepare and commit that for DB2 fail all except the first one. I understand that this impacts perfomance, but the other option. My operating system is WinXP, JDK1.3.1_06. I have looked in Jboss 3.2.2 source and I see that basically the code is the same. Please confirm that this is in fact the way to solve the problem. -- Comment By: Adrian Brock (ejort) Date: 2003-10-09 17:07 Message: Logged In: YES user_id=9459 Minerva hasn't been in jboss for a while, 2.4 I think The transaction implementation is different between 3.0 and 3.2, I can only suggest testing it. TrackConnectionByTx is available in 3.0 as an attribute on the XATXConnectionManager (I'm not sure when it was added, 3.0.7 I think). Regards, Adrian -- Comment By: Eduard Letifov (techtime) Date: 2003-10-09 16:57 Message: Logged In: YES user_id=438410 Adrian, Yes, you are correct in regards to 3.2. I meant the enlist part. I will try the test with 3.2 right now. Meanwhile a question: is it possible to comment out the same lines in 3.0.8 or does it still have the 'Minerva crap'? I don't think I will be able to present our customers with 3.2 gift for their AS400. I wish I wasn't anywhere near AS400 either Ed. -- Comment By: Adrian Brock (ejort) Date: 2003-10-09 16:28 Message: Logged In: YES user_id=9459 The code is not the same in the 3.2 branch. Look at endResources in TransactionImpl.java and the comment about minerva. There is also the option to track-connection-by-tx where you can force a resource to remain in the enlisted state until the transaction completes. Please try your test with 3.2 without modification. If this doesn't work, please provide information about the problem you are seeing and enable TRACE logging for org.jboss.tm and org.jboss.resource in conf/log4j.xml The output will go into log/server.log I don't personally have an AS/400 :-) I do have a copy of Oracle if you want to provide a testcase. Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=820711group_id=22866 --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php
