RP/TUX 9.0 - Tuxedo non-TMS servers do not reopen failed dynamically registering RM but do reopen failed statically registering RM

(Doc ID 777022.1)

Last updated on NOVEMBER 04, 2016

Applies to:

Oracle Tuxedo
Information in this document applies to any platform.

Goal

When an XA operation returns XAER_RMFAIL, the XA Transaction Branch Association State is set to state R0
(Un-initialised) in XA CAE Specification Tables 6-2 (Static Registration), 6-3 (Dynamic Registration), and 6-4
(transaction branch associations).  In state R0, the only allowable operation is xa_open() [Table 6-1], and the XA CAE
Specification states that "A transition to state R1 enables the use of Table 6-2 on page 59 to Table 6-4 on page
62 inclusive.  The state R0 in these tables to illustrate that closing an RM precludes its use in global transactions.
 At this point, Table 6-1 governs legal sequences.  In Table 6-2 on page 59 to Table 6-4 on page 62 a return of
[XAER_RMFAIL] on any routine causes a state transition in that thread to state R0."

When XAER_RMFAIL occurs in a TMS server, the TMS attempts to reopen the RM, and does so regardless of whether dynamic
or static registration is in use.

When XAER_RMFAIL occurs in a statically registering application server, the server attempts to reopen the RM when the
next request arrives.  It does so in _tmtran_recv_rqst() by noticing the XAER_RMFAIL return from xa_start(), calling
xa_open(), and retyring the xa_start() if xa_open() succeeds.

When XAER_RMFAIL occurs in a dynamically registering application server, no attempt is made to reopen the RM when the
next request arrives, since the TM does not call xa_start() and depends on the RM to call ax_reg().  The problem is
that Table 6-3 does not allow ax_reg() as a legal operation until xa_open() is done.  This is causing problems and a
difference in application behavior between dynamic registration and static registration for the Oracle RM when
failover occurs (CR238761), and may also cause problems for other dynamically registering RMs.  The problem is showing
up in Oracle RAC testing because RM failover is being tested, but it is not specific to RAC.

To fix the problem, should add code in _tmtran_recv_rqst() to retry xa_open() if neither TMGNULLRM nor TMGRMOPEN is
set in TUXC->_TUXC__tmgtranflags and TMREGISTER is set in the process' XA switch.  Since some customers may have
written application code to call tx_open() or tpopen() on certain SQL failures, a return either XA_OK or XAER_PROTO
(indicating the RM is already open) should be treated as a successful reply from the retry of xa_open().

Solution

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms