Hello,
is there anyone with some experience using tuxedo with XA and RAC, and willing to share their experience?
We are embarking to support RAC for our Tuxedo XA (Corba) application. We are looking for some guidance on how to handle failover.
Our application has both XA and non-XA components. Both are currently written with the assumption that there is one DB that is always available. Should the DB (or the network to it) fail, the application exits and is restarted. The connection is established in the initialization part of the application. The general error handling strategy is to roll-back the complete transaction (operation) and retry it anew. The application is in C++ and uses OCI to communicate with the DB. The target is Oracle 11g and Tuxedo 10.
We are aware of the following options:
1) OCI connection pools. This seems to work only for multi-threaded processes. Our Tuxedo processes are single-threaded.
2) TAF and FAN. I am concerned about the number of FAN notifications, as there can be over 100 processes with DB connections. And I am not sure what kind of notifications the applications should handle (if any), ie. how transparent it really is to the Tuxedo XA processes.
3) The application doing a disconenct and reconnect when it detects a failure, in conjunction with a DTP service. In some initial testing we have not been able to make this work. And the big disadvantage is that each application has to make a request (which will fail) to trigger the failover.
Roger
Hi Roger
refresh the database connection manually per service call using:
xaoEnv(db_name);
and
xaoSvcCtx(db_name);
Let tuxedo handle the recovery and reconnect.
i.e call tpopen only once.
and
export TUXWA4ORACLE=y
follow "Ed Heeren" suggestion in this thread.
The reason is that TMS_ORACLE does FAN/TAFF and reconnect for you.
As for the non-xa connections, i am really not sure but it would be as in any other application regardless of tuxedo.
* One solution is to reconnect on error
* Another solution you may use is FAN or TAFF for that your self.
BUT BE AWARE fan callbacks are on a different thread !!! meaning you cannot use this callback to call tuxedo API without a context.
See this thread:
http://forums.oracle.com/forums/message.jspa?messageID=3557970#3557970
Regards
Tech Sgin
Edited by: TechSgin on Feb 25, 2011 5:05 PM
Hi Roger,
For services that are called in the context of a Tuxedo transaction, i.e., XA transaction, Tuxedo will re-establish the database connection for you in the case of a connection failure. For servers not using XA, Tuxedo has no way of even knowing that a database connection exists, and as such cannot manage the connection recovery for you.
If you are worried about FAN notifications, you could always have the FAN notification post a Tuxedo event that you subscribe to and then let Tuxedo worry about notifying the Tuxedo components.
Regards,
Todd Little
Oracle Tuxedo Chief Architect
Hi Todd
We are using XA and our Tuxedo is not able to process transactions after a failover. We are also using Oracle DB 11.2 and Tuxedo 10.
Do we still need to have
xaoEnv(db_name);
and
xaoSvcCtx(db_name);
in our code as suggested by Tech Sgin in the previous post or should it all just work.
This is the sort of error that we get after a failover (see below) and we cannot perform further transactions unless we restart Tuxedo.
From our ULOG...
114629.server101l!BlahService.413818.1.0: LIBTUX_CAT:486: ERROR: Service request problem, tperrno = 14
114629.server101l!BlahService.172368.1.0: LIBTUX_CAT:486: ERROR: Service request problem, tperrno = 14
133836.server101l!BlahService.245764.1.0: gtrid x0 x4c15a416 x12ed3c: LIBTUX_CAT:1384: ERROR: xa_start flags 0 returned -7
133836.server101l!BlahService.245764.1.0: LIBTUX_CAT:486: ERROR: Service request problem, tperrno = 14
133836.server101l!BlahService.245764.1.0: LIBTUX_CAT:466: ERROR: tpopen TPERMERR xa_open returned XAER_RMERR
133836.server101l!BlahService.245764.1.0: LIBTUX_CAT:486: ERROR: Service request problem, tperrno = 9
Cheers,
MikeK
Mike,
Please verify that you have the environment variable
TUXWA4ORACLE=y
set in your environment.
After an XA call returns XAER_RMFAIL (-7) most resource managers allow another xa_open() to be done immediately. However, Oracle database and some other resource managers interpret the XA standard differently and require that an xa_close() be done before another xa_open() can be sucessfully issued.
When the TUXWA4ORACLE environment variable is set (to any value), Tuxedo performs an xa_close() following an XAER_RMFAIL before performing an xa_open(). Thus, this environment variaable is required in an Oracle database environment for proper recovery following a resource manager failure.
Regards,
Ed
Ed, you're a genius!
Once we exported this environment variable, everything started working just fine.
We are now able to perform failovers gracefully.
Thank you very much for helping us out with this one.
Cheers,
Mike
Hi
I never heard of the TUXWA4ORACLE environment variable before. We are having similar issues with Tuxedo 8.1 and Oracle 10.2.0.4. Is this environment variable supported in that configuration?
Thanks
Tom
While we are still struggling with TUXEDO, XA, RAC failover using OCI we have found the following usefull links:
Best Practices for Using XA with RAC
http://www.oracle.com/technetwork/database/enterprise-edition/bestpracticesforxaandrac-128676.pdf
XA and Oracle controlled Distributed Transactions
http://www.oracle.com/technetwork/database/clustering/overview/distributed-transactions-and-xa-163941.pdf
Interesting\good comment about timeouts:
Generally, these timeouts should be set in the following order:
1. TM’s global transaction timeout (or the JTA timeout) <
2. SesTm and SesWt (Transaction Timeout for JDBC or PL/SQL) <
3. DISTRIBUTED_LOCK_TIMEOUT <
4. Either of CONNECT_TIME or IDLE_TIME
Tuxedo tmadmin print transaction documentation:
http://download.oracle.com/docs/cd/E13203_01/tuxedo/tux64/tag/adminops.htm
Hope you will find it helpful.
Regards
TechSgin