RP/TUX 9.0 - Tuxedo non-TMS servers do not reopen failed dynamically registering RM but do reopen failed statically registering RM
Last updated on JANUARY 19, 2018
Applies to:Oracle Tuxedo
Information in this document applies to any platform.
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().
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms