the code that generates the 2nd and 3rd part of the global xid is some
ij specific code there to make writing ij based tests a litte easier.
The id's are generated from the database token in the ij parser - I am
guessing at that point the strings are still in their native form,
see xaHelper.java:
databaseName = parser.stringValue(dbname.image);
One fix is just to change the tests to have them provide all 3 parts of
the global XID, this is what is usually done in a jdbc program.
Myrna van Lunteren (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-576?page=comments#action_12329844 ]
Myrna van Lunteren commented on DERBY-576:
------------------------------------------
Any other ideas as to what could cause a different id? The diff is like this:
(only showing value of first column - GLOBAL_XID - of the select in
xa/xaOffline1, the rest is the same):
GLOBAL_XID
expected:
(1,776f6d626174,776f6d626174)
actual:
(1,a696948281a3,a696948281a3)
xaHelper in ij creates global id that is not the same across platforms
----------------------------------------------------------------------
Key: DERBY-576
URL: http://issues.apache.org/jira/browse/DERBY-576
Project: Derby
Type: Bug
Components: Test
Versions: 10.1.1.0
Environment: OS/390 (z/OS 1.06) with IBM j2RE 1.4.2.
Reporter: Myrna van Lunteren
Priority: Minor
The test xa/xaOffline1 fails on OS/390 because the global_xid generated by ij is different.
This value is created in org.apache.derby.impl.tools.ij.xaHelper - which class is only for testing. It tries to generate a the 2nd and 3rd part of the global_xid based on the database name, and in method XADataSourceStatement it is trying to do this by doing parser.stringvalue(dbname.image). It would be nice if this could get changed to something that gives the same result in ASCII and EBCDIC.
