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=detail&atid=376685&aid=820711&group_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="TrackConnectionByTx">true</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 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=detail&atid=376685&aid=820711&group_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
