Table of Contents
This is special ATMI server which is used for distributed transaction coordination. For new transactions started with tpbegin(), tmsrv generates new XID and passed it back to transaction initiator. At the same time transaction is remembered by tmsrv as active transaction and time-out counter is checked by background thread.
In Enduro/X XA Resource Managers are numeric identifiers, which are allowed to be in range of 1..32. Enduro/X’s Resource Manager ID (RMID) is same identifier as Group Number or grpno known in other ATMI systems.
If during distributed transaction processing new resource manager is associated with transaction, then process notifies initial transaction manager that new association must be made. In active phase this too is stored in process memory.
When transaction comes to commit() phase, then it is logged to disk. Every transaction is logged to separate file. File name contains resource manager ID and transaction XID. During the prepare phase status of every Resource Manager is logged. The same is with commit phase. Once all resources are completed, transaction file is removed. If tmsrv crashed for in-progress transaction, then transaction files are read from disk, and appropriate actions according to state machine are performed (aborted or rolled back).
If running transaction did time-out, then background thread will abort it automatically, and for caller process commit() will fail with abort-only message.
In cluster environment, other transaction manager of corresponding resource managers are involved for prepare/abort/commit actions. Also as every service doing as part of single transaction, must have a cluster link to initial transaction manager (for registration purposes). Thus means that all involved nodes, must have direct cluster visibility, otherwise transactions will fail.
Transaction managers can be load balanced with ndrxconfig.xml with min/max attributes. In load balance manner at tpbegin() corresponding free transaction manager will be selected. Later at transaction process this manager is responsible for full cycle of the transaction. Other resource managers for this transaction will help for prepare/commit/aborts of other RMs. These other TMs will be selected in load balanced mode.
Every instance of tmsrv will advertise following list of services
For example for Resource Manager ID 1, Cluster Node ID 6, Enduro/X Server ID 10 services will look like:
Currently 1. format is used for starting the transaction, and accepting prepare/commit/abort calls from master TM of the transaction. Service Nr 3. is used by transaction initiator for subsequent calls of the tpcommit()/tpabort(). Also 3. is used by services involved in transaction to register new Resource Manager ID as part of the transaction.
For XA processing, resource manager drivers are loaded via dynamic loadable shared libs. Resource manager should expose xa_switch in shared lib. For every different resource manager, there is different Enduro/X server running. Enduro/X process gets associated with corresponding RMDI via NDRX_XA_RES_ID environment variable.
To configure different RMID’s for different processes or tmsrvs. Use the Enduro/X build in facility of environment variable override. See the manpage of ex_env(5).
Enduro/X support static and dynamic XA registration.
The -R mode might not be enabled in database for user. I.e. user is not allowed to see open transactions. Thus must be enabled by following commands on DB user set in XA open string:
grant select on pending_trans$ to <database_user>; grant select on dba_2pc_pending to <database_user>; grant select on dba_pending_transactions to <database_user>; grant execute on dbms_system to <database_user>; (If using Oracle 10.2) grant execute on dbms_xa to <database_user>; (If using Oracle 10.2)
If planing to use Oracle RAC, the to successfully process distributed transaction across binaries which are connected to different RAC nodes, Oracle RAC DTP Service must be configured. If this is not possible, then other option is to configured particular DTP binaries to connect only to one RAC node (which gives less fault tolerance).
If this above is not configured and say two binaries are working with same XA transaction, one binary is connected to first RAC node and other binary with second RAC node, the transaction will not work, as XA API will not see the transaction on other node than where it was started.
Report bugs to support@mavimax.com