Enduro/X Core

Hi Muralidhara,

Welcome to Enduro/X forum.

To do interaction with two different Resource Managers, you need to use two processes. One XATMI process can operate only with one particular kind of Resource Manager.

You can use one resource manager with "client1" (say IBM MQ) and create "server1" process to interact with Oracle DB. The if you do tpcall or tpconnect from client1 to server1 (and exchange with data between these processes), these data/changes of RMs (MQ/ORADB) both will pass under the same XID. When client process has global txn open, and it connects to server process, the server process would automatically be joined in that original client transaction.

Then in the end, if client1 do tpcommit(), then both MQ and Oracle changes would be committed together.

In such case you need to configure two tmsrv, where one has cctag of MQ_TAG and other tmsrv with ORA_TAG.

Then client1 you start with NDRX_CCTAG=MQ_TAG, but server1 you configure in ndrxconfig.xml with <cctag> set to <ORA_TAG>.

Let me know, more if more help needed.

I have configured two tmsrv only, one for IBM MQ and one for oracle(ORA_TAG), Please carefully take a look at my app.ini and ndrxconfig.xml changes.

Also I didn't understand why we need to create server1 to interact with oracle DB? because all our business logic is in client application code, where we put the message to IBM queue and update the oracle database tables, then we do MQ commit and DB commit. We don't want to move this business logic outside of this.

app.ini:
[@global/MQ_TAG]
NDRX_XA_RES_ID=1
NDRX_XA_OPEN_STR=QMNAME=MNDBV
NDRX_XA_CLOSE_STR=$NDRX_XA_OPEN_STR
NDRX_XA_DRIVERLIB=/usr/lib64/libndrxxawsmqs.so
NDRX_XA_RMLIB=/opt/mqm/lib64/libmqmxa64_r.so
NDRX_XA_LAZY_INIT=1

[@global/ORA_TAG]

NDRX_XA_RES_ID=2
NDRX_XA_DRIVERLIB=/usr/lib64/libndrxxaoras.so
NDRX_XA_RMLIB=/oracle/product/19.28_client/lib/libclntsh.so
NDRX_XA_OPEN_STR=ORACLE_XA+SqlNet=158.234.207.204:1521/hot199perf+ACC=P/MNPRDDUMPMAY/banana12+SesTM=180+Threads=true
NDRX_XA_CLOSE_STR=ORACLE_XA+SqlNet=158.234.207.204:1521/hot199perf+ACC=P/MNPRDDUMPMAY/banana12+SesTM=180+Threads=true
NDRX_XA_LAZY_INIT=1
ENV:ORACLE_HOME=/oracle/product/19.28_client
ENV:LD_LIBRARY_PATH=/opt/mqm/lib64:/oracle/product/19.28_client/lib:/home/nagaraju/lib:/usr/lib64

ndrxconfig.xml:

<server name="tmsrv">
<min>3</min>
<max>3</max>
<srvid>40</srvid>
<cctag>MQ_TAG</cctag>
<sysopt>-e ${NDRX_ULOG}/tmsrv-rm1.log r - t1 -l${NDRX_APPHOME}/tmlogs/rm1</sysopt>
</server>

<server name="tmsrv">
<min>3</min>
<max>3</max>
<srvid>50</srvid>
<cctag>ORA_TAG</cctag>
<sysopt>-e ${NDRX_ULOG}/tmsrv-ora.log -r - -t4 -l${NDRX_APPHOME}/tmlogs/ora</sysopt>
</server>

Also I didn't understand why we need to create server1 to interact with oracle DB?

Currently this is not supported by Enduro/X. However, multiple xa switches support per binary is planned for future releases.

Thanks for the confirmation.

Can you please explain how we can interact with 2 different resource manager with current enduroX release?

Can you explain more on previous statement *"To do interaction with two different Resource Managers, you need to use two processes. One XATMI process can operate only with one particular kind of Resource Manager." *

How we can achieve this?

Thanks for the confirmation.

Can you please explain how we can interact with 2 different resource manager with current enduroX release?

Can you explain more on your previous statement:

You can use one resource manager with "client1" (say IBM MQ) and create "server1" process to interact with Oracle DB. The if you do tpcall or tpconnect from client1 to server1 (and exchange with data between these processes), these data/changes of RMs (MQ/ORADB) both will pass under the same XID. When client process has global txn open, and it connects to server process, the server process would automatically be joined in that original client transaction.

How we can achieve this? Can you please explain in detail?

Hi Muralidhara,

Please find sample app attached (demo_app.zip).
It demonstrates the approach of doing batch transfer in single XA transaction from TMQ and PostgreSQL database.
src/qtransfer uses tpconnect/tpsend - conversation mode to handle transfer in single txn
src/qtransfer2 uses tpcall() API handle transfers in single txn

correspondingly src/pgwritesv xatmi server provides two services - "PGWRITE" for batch conversational data receive and insert into DB under single global txn. And "PGWRITE2" inserts one record at call used by tpcall(), but here also those many calls would fall under single global transaction.

TMQ and PostgreSQL database are just two resources to demonstrate how to operate with them. You can use similar principle for IBM MQ -> Oracle transfers.

(demo_app.zip attached)

Thanks

Attached slightly simplified version of src/qtransfer (tpconnect/tpsend) + and simplified PGWRITE service code.

Hello,

Thanks. Will try to make the similar changes for IBM MQ and oracle DB and see if it works.

Hello,

Went through the demo_app2.zip attached,

For our requirement we can conside only "*src/pgwritesv*" & "*src/qtransfer2*" and we can ignore "*src/qtransfer/*" & "*src/qgen/*" ??

What we understood is we can make IBM MQ related changes similar to src/qtransfer2 and use tpcall() to src/pgwritesv to make oracle DB related changes.

Please confirm whether our understanding is correct or not.

What we understood is we can make IBM MQ related changes similar to src/qtransfer2 and use tpcall() to src/pgwritesv to make oracle DB related changes.
Please confirm whether our understanding is correct or not.

Yes, correct. And in pgwritesv only see "PGWRITE2" service, and ignore "PGWRITE".

Thanks

Hello,

If we do any oracle DB updates in qtransfer2 after tpcall() to pgwritesv, will those changes be committed when we call tpcommit() in qtransfer2 * ? *or any updates to oracle DB should be done in pgwritesv only and then only it will be commited?

Hi,

You can call services which modify oracle db records multiple times in the same transaction. And then do common tpcommit. As I understand you plan to have qtransfer2 like binary to work with ibmmq thus oracle modifications shall be done by service calls / tpcall. You can do many service calls in single global txn.

Thanks

Hello,

Thanks for the demo app and it helped.

Now we are able to commit both ibm mq and oracle with the endurox tpcommmit().

We are trying to forcefully close IBM mq queue manager after the succesfull tpcall() and before tpcommit() with 8 seconds of sleep.

Yes, the transaction is getting aborted when we close the IBM mq queue manager and when we start the IBM mq queue manager again, transaction is not completing.

But it completes(commit OK) when we stop and start the endurox(xadmin stop and xadmin start) !

Can you please let us know when the IBM queue manager again, why the transaction is getting completed when we start the IBM mq manager again?

Please see we have attached all the logs.

Hi,

But it completes(commit OK) when we stop and start the endurox(xadmin stop and xadmin start) !

At which moment and exactly what you did restart?

So in IBM MQ client (client_logs.txt), there was:

- begin txn
- tpcall
- sleep 8
- exactly what was restarted during sleep? Full Enduro/X App or some service?
- the commit succeeded?

Or it was different scenario?

Thanks

Hello,

after sleep(8) is called,

-- Stop the IBM mq manager(endmqm i MNDBV105)
- Commit fails/aborts and our clinet application also restarts.
-- Wait for one min and then start the IBM mq manager(strmqm MNDBV105), but commit did not succeed.
-- Restart full enduro/X App(xadmin stop -y and xadmin start -y), then commit succeeded.

-- Restart full enduro/X App(xadmin stop -y and xadmin start -y), then commit succeeded.

Can you please identify which transaction id in the log you refer to?

The last one in client_logs.txt did succeed (YZT3oUBAAQAyZGeVyWth4GpzdWUKSwEAAQAo), I do not see that transaction manager was restarted (the PID is the same):

000.000007|srv-rm1(1).log|N:NDRX:4:ad4c0b65:3302503:15367ddff640:003:20260805:230949249169:bug_dump_UBF:/utils.c:0253:TPTMSRV return buffer:
000.000007|srv-rm1(1).log|TMNODEID    1
000.000007|srv-rm1(1).log|TMRMID    1
000.000007|srv-rm1(1).log|TMSRVID    40
000.000007|srv-rm1(1).log|TMERR_CODE    0
000.000007|srv-rm1(1).log|TMERR_REASON    0
000.000007|srv-rm1(1).log|TMCALLERRM    1
000.000007|srv-rm1(1).log|TMTXTOUT    10
000.000007|srv-rm1(1).log|TMTXFLAGS    0
000.000007|srv-rm1(1).log|TMTXBTID    0
000.000007|srv-rm1(1).log|TMCMD    b
000.000007|srv-rm1(1).log|TMXID    YZT3oUBAAQAyZGeVyWth4GpzdWUKSwEAAQAo
000.000007|srv-rm1(1).log|TMKNOWNRMS    \01
000.000007|srv-rm1(1).log|TMERR_MSG    Success
000.000007|srv-rm1(1).log|TMPROCESSID    clt,hotput,3302574,1,1
...
000.000036|lient_logs.txt|N:NDRX:4:ad4c0b65:3302574:15485f852b40:001:20260805:230955266870:bug_dump_UBF:/utils.c:0253:Request buffer:
000.000036|lient_logs.txt|TMNODEID        1
000.000036|lient_logs.txt|TMRMID  1
000.000036|lient_logs.txt|TMSRVID 40
000.000036|lient_logs.txt|TMCALLERRM      1
000.000036|lient_logs.txt|TMTXFLAGS       0
000.000036|lient_logs.txt|TMCMD   c
000.000036|lient_logs.txt|TMXID   YZT3oUBAAQAyZGeVyWth4GpzdWUKSwEAAQAo
000.000036|lient_logs.txt|TMKNOWNRMS      \01\02
000.000036|lient_logs.txt|TMPROCESSID     clt,hotput,3302574,1,1
...
000.000006|srv-rm1(1).log|N:NDRX:4:ad4c0b65:3302503:1536757fa640:011:20260805:230955272402:bug_dump_UBF:/utils.c:0253:Response buffer:
000.000006|srv-rm1(1).log|TMNODEID    1
000.000006|srv-rm1(1).log|TMRMID    1
000.000006|srv-rm1(1).log|TMSRVID    40
000.000006|srv-rm1(1).log|TMERR_CODE    0
000.000006|srv-rm1(1).log|TMERR_REASON    0
000.000006|srv-rm1(1).log|TMCALLERRM    1
000.000006|srv-rm1(1).log|TMTXFLAGS    0
000.000006|srv-rm1(1).log|TMTXBTID    0
000.000006|srv-rm1(1).log|TMCMD    P
000.000006|srv-rm1(1).log|TMXID    YZT3oUBAAQAyZGeVyWth4GpzdWUKSwEAAQAo
000.000006|srv-rm1(1).log|TMKNOWNRMS    \01\02
000.000006|srv-rm1(1).log|TMERR_MSG    Success
000.000006|srv-rm1(1).log|TMPROCESSID    srv,tmsrv,40,3302503,11,1

The tmsrv with pid= 3302503 did process it fully...

tmsrv would rollback txns automatically at startup for which commit decision was not logged.
Commit decision is logged when all branches prepared and in tmsrv per-txn log file "about to commit" status written.
Basically if there were not commit, and enduro/x was restarted, the tmsrv at startup would read the logs and put those txns automatically in rollback state.

Ok. Understood.

One clarification:
You had told that multiple xa switches support i.e, multiple resource manager is not supported per binary.

But multiple xa switches support is supported per enduro server process? i.e,. server process created using the buildserver ?

But multiple xa switches support is supported per enduro server process? i.e,. server process created using the buildserver ?

In current release v8 (and older), situation is the same 1x xa switch in the server too.

However, in upcoming v9 Enduro/X multiple xa switches would be supported for servers & clients. If you are interested, we can provide you development preview version in 2 weeks, where multiple switches are supported (i.e. in NDRX_CCTAG you would be able to point to multiple ini sub-section holding different NDRX_XA... configs).

Let me know, if you want to try out this, and if so, for what operating system preview-release shall be made? In Enduro/X v9 multiple switches can be dynamically loaded, or linked by buildclient/buildserver.

Thanks