Enduro/X Core

Hi,

Welcome to Enduro/X forums.

Just checked, that DB2 loader driver has a bug, /endurox/lib64/libndrxxadb2s.so resolves loader function db2xacicst_std() instead of XA switch db2xa_switch_static_std.
We will need to rebuild Enduro/X libndrxxadb2s.so to have correct xa switch name, that could be done in the next week, when plan the patch release for Enduro/X 7.5.

There are several things you can do now:

1) If you are familiar with Tuxedo environment, you could use buildtms tools in the same way as with Tuxedo and follow for example this procedure: https://www.ibm.com/docs/en/db2/11.1?topic=managers-bea-tuxedo

In that case the CCTAG would look like this:

ini:

[@global/RM1_DB2]
NDRX_XA_RES_ID=2
NDRX_XA_OPEN_STR=”db=MG2211CR,uid=dbuser,pwd=Test1234,toc=t”
NDRX_XA_CLOSE_STR=${NDRX_XA_OPEN_STR
NDRX_XA_DRIVERLIB=/endurox/lib64/libndrxxatmsx.so
NDRX_XA_RMLIB=-
NDRX_XA_LAZY_INIT=1

And the you need to use custom built tms:

xml:

<server name="output_from_build_tms">
<min>1</min>
<max>1</max>
<srvid>46</srvid>
<cctag>RM1_DB2</cctag>
<sysopt>-e ${NDRX_APPHOME}/log/tmsrv-rm2.log r - -t1 -l${NDRX_APPHOME}/tmlogs/rm2</sysopt>
</server>

This would allow you to proceed with the testing.

By the way, if you are familiar with Tuxedo environment, for Enduro/X version 8.0 (which is not yet released), we will provide automatic tool for configuration migration and we have made extensive migration guide, that I guess would help for 7.5 migrations too, if that is the case, see
https://github.com/endurox-dev/endurox/blob/7.1/doc/migration_tuxedo.adoc

2) Second option if you want to proceed now, would be that you rebuild the Enduro/X by your self, prior updating https://github.com/endurox-dev/endurox/blob/master/xadrv/db2/db2_s.c

< return ndrx_get_xa_switch_int("db2xacicst_std", "Loading Db2 Static reg XA driver"); 
> return ndrx_get_xa_switch_int("db2xa_switch_static_std", "Loading Db2 Static reg XA driver");

PS,

According to IBM, DB2 XA Switch have TMNOMIGRATE flag, this means that additionally you need to add configuration flag NOJOIN, which would enable loose coupling between the transaction branches:

[@global/RM1_DB2]
NDRX_XA_RES_ID=2
NDRX_XA_OPEN_STR=”db=MG2211CR,uid=dbuser,pwd=Test1234,toc=t”
NDRX_XA_CLOSE_STR=${NDRX_XA_OPEN_STR
NDRX_XA_DRIVERLIB=/endurox/lib64/libndrxxatmsx.so
NDRX_XA_RMLIB=-
NDRX_XA_LAZY_INIT=1
NDRX_XA_FLAGS=NOJOIN

If the DB changes needs to be seen between processes, you may try to add BTIGHT flag, such as:

NDRX_XA_FLAGS=NOJOIN;BTIGHT

Though, not sure how well DB2 would support that. In any case, you may try out and provide results. Also when NOJOIN is used, you shall not explicitly use tpsuspend()/tpresume() calls in your software (if they are used, as here tpsuspend() will just end the transaction branch and would not resume it the same thread, instead new branch would be created).

Currently we do no not have test system with DB2, as Enduro/X operates according to XA specification and we are assuming that DB2 complies as well. But in any case if prospects are good we can fine tune our product for DB2 (if that would be required).

Thought if using buildtms option, then DB2 processes shall be built with buildserver/buildclient by using -r parameter.

Thank you Madars, we will go through the workaround options and revert if it worked or need more help

We double checked the TMNOMIGRATE setting of DB2 xa switch, and that affects only association migration between a threads, which Enduro/X is not doing. So I guess you could start testing with "NDRX_XA_FLAGS" unset i.e. no specific settings used.

And one more moment:

You do not need quotes around the open/close strings when putting settings in ini file, e.g.:

[@global/RM1_DB2]
NDRX_XA_RES_ID=2
NDRX_XA_OPEN_STR=db=MG2211CR,uid=dbuser,pwd=Test1234,toc=t
NDRX_XA_CLOSE_STR=${NDRX_XA_OPEN_STR}
...

That would be the correct way.

Hello,

Fixed version have been uploaded: https://www.endurox.org/attachments/download/1524/endurox-7.5.36-1.oracleserver7_3_GNU_epoll.x86_64.rpm

Now correct XA Switch names are being used in DB2 drivers.

Hi Madars and Lauris,

Thank you . We were able to successfully configure IBM DB2 with the endurox-7.5.36-1 version . We are able to execute the queries successfully as well

A follow up to this question , we are using Endurox as a Transaction manager with IBM DB2 as resource manager 1 and Postgres as resource manager 2.

Following configuration allows only one RM as part of the tmsrv(transaction manager) in cctag. How do we configure the Postgres resource manager as well as part of this transaction manager? We want to make a DB2 operation and also a Postgres operation as part of a single transaction

<server name="tmsrv">
<min>1</min>
<max>1</max>
<srvid>46</srvid>
<cctag>RM1_DB2</cctag>
<sysopt>-e ${NDRX_APPHOME}/log/tmsrv-rm2.log r - -t1 -l${NDRX_APPHOME}/tmlogs/rm2</sysopt>
</server>

Hi,

You need to define several different tmsrv for each of the cctag.

You can check sample xml config here: https://github.com/endurox-dev/endurox/blob/master/atmitest/test090_tuxmig/ubb_config1.xml with corresponding ini config here: https://github.com/endurox-dev/endurox/blob/master/atmitest/test090_tuxmig/ubb_config1.ini where several CCTAGs and tmsrvs are used.

The system will automatically join required tmsrvs in the global transaction.

So something like this for your case:

[@global/RM1_DB2]
NDRX_XA_RES_ID=1
NDRX_XA_OPEN_STR=db=MG2211CR,uid=dbuser,pwd=Test1234,toc=t
NDRX_XA_CLOSE_STR=${NDRX_XA_OPEN_STR}
NDRX_XA_DRIVERLIB=/endurox/lib64/libndrxxadb2s.so
NDRX_XA_RMLIB=/opt/ibm/db2/V11.1/lib64/libdb2.so
NDRX_XA_LAZY_INIT=1
NDRX_XA_FLAGS=FDATASYNC;DSYNC

[@global/RM2_PQ]
# remember to have different RES_IDs for each of the CCTAG:
NDRX_XA_RES_ID=2
NDRX_XA_OPEN_STR={ "url":"postgresql://${EX_PG_USER}:${EX_PG_PASS}@${EX_PG_HOST}/${EX_PG_DB}"}
NDRX_XA_CLOSE_STR=${NDRX_XA_OPEN_STR}
NDRX_XA_DRIVERLIB=libndrxxapq.so
NDRX_XA_RMLIB=-
NDRX_XA_LAZY_INIT=1
NDRX_XA_FLAGS=FDATASYNC;DSYNC;NOJOIN;NOSTARTXID

And then in xml config:

<endurox>
...
<servers>
...
<server name="tmsrv">
<min>1</min>
<max>1</max>
<srvid>46</srvid>
<cctag>RM1_DB2</cctag>
<sysopt>-e ${NDRX_APPHOME}/log/tmsrv-rm1.log r - -t1 -l${NDRX_APPHOME}/tmlogs/rm1</sysopt>
</server>

<server name="some_business_binary1">
<cctag>RM1_DB2</cctag>
...
</server>
...

<server name="tmsrv">
<min>1</min>
<max>1</max>
<srvid>146</srvid>
<cctag>RM2_PQ</cctag>
<sysopt>-e ${NDRX_APPHOME}/log/tmsrv-rm2.log r - -t1 -l${NDRX_APPHOME}/tmlogs/rm2</sysopt>
</server>

<server name="some_business_binary2">
<cctag>RM2_PQ</cctag>
...
</server>
...

remember to create: ${NDRX_APPHOME}/tmlogs/rm1 (probably you have already this) and ${NDRX_APPHOME}/tmlogs/rm2.

And another note, by default tmsrv does not fsync to disk at point of transaction commit decision, just fflush. So to guarantee transaction consistency for case of power loss or OS crash, FDATASYNC;DSYNC flags are required, though if slow disks are used for -l${NDRX_APPHOME}/tmlogs, expect low TPS throughput.

Br,
Madars

Thank you Madars,

We have setup two tmsrv for each resource manager.
But our business application server needs to make execute both DB2 and Postgres queries in a single transaction.

//code something like below
begin XA transaction
call PG database query
call DB2 database query
commit/rollback XA transaction

We are unable to create this server , since the ND_XA_* config parameters in app.ini correspond to one RM . The query executes for PG, but fails for DB2 and transaction is rolled back.

Hi,

XATMI API does not work this way.

Single xatmi client or server is linked only with one resource, in this case either PG or DB2 according to CCTAG and libraries used...

If you need a transaction which spans over the two or more databases, you need to use following architecture:

1) You create an orchestrator process which will start the global transaction. Orchestrator may live in NULL RM switch/TMSRV, see libndrxxanulls. I.e. dummy resource associate with it.
2) You create a XATMI server/service for works that shall be done under DB2.
3) You create a XATMI server/service for works that shall be done under PG.

And then at runtime:

A) The Orchestrator 2) starts a transaction
B) Orchestrator process calls (i.e. use tpcall() to send request+data) the DB2 XATMI service created at 2). Enduro/X will automatically join the DB2 to the global transaction started at A).
C) Orchestrator process calls the PG service created at 3). The same here, Enduro/X will associate PG work with global txn started at A).
D) Orchestrator commits the transaction.

Hope this help!

Br,
Madars

Also Orchestrator may be any of PG or DB2 services, and they can tpcall() each other as required. The main idea is that each executable works only with on resource and other resources are involved in global transaction via tpcall() or other XATMI apis (i.e. tpacall()/tpgetrply(), tpconnect() + tpsend() + tprecv(), etc.)

Thank you for the detailed explanation
We will test our application this way