This discussion is archived
8 Replies Latest reply: Aug 13, 2013 12:40 AM by Per Lindström RSS

Auto Reconnection of Oracle Tuxedo 11.1.1.2.0, 64-bit to Oracle Data Base

985149 Newbie
Currently Being Moderated
Hi Dear,

We have Recently Migrated to Oracle Tuxedo 11.1.1.2.0 Running on RHEL 6.3 and connecting Oracle Data Base 11.0.2.0.

We are informed by the Oracle Tuxedo Support that This tuxedo version Automatically re-connects to the oracle database once the Data base is rebooted.

Because of the above impression we removed all our reconnection code from our applications.
But unfortunately the servers are not automatically re-connecting to Oracle DB.

Can you Please let us know, whether really this version automatically re-connects to Oracle DB??
If Yes, How?? I mean is there any specific configuration to be done on Tuxedo??

Thanks in Advance .... :)

Rgds,
Plaban
  • 1. Re: Auto Reconnection of Oracle Tuxedo 11.1.1.2.0, 64-bit to Oracle Data Base
    682629 Journeyer
    Currently Being Moderated
    Plaban,

    There are two ways to manage connections to Oracle Database (or any other XA compliant resource manager) with Tuxedo.

    One way is to use the XA interface. This involves spcifying information about the resource manager in $TUXDIR/udataobj/RM, building TMS servers linked with the resource manager, using the "-r rmname" option on buildserver, and specifying the TMS server names and an OPENINFO string *GROUPS section of the UBBCONFIG file.  When this option is chosen, application servers will not contain any logic to connect to or disconnect from the database and appllication servers will not contain any SQL statments to COMMIT WORK or ROLLBACK WORK.  All of this will be managed by Tuxedo.  If an XA call indicates that the resource manager is unavailable, Tuxedo will try to reconnect to the resource manager when subsequent tranasctional requests are received.  (Note that if a server in an XA-associated group receives requests outside of transaction mode, then Tuxedo will not issue any XA calls and will not know if there are any problems with the database.  You can specify AUTOTRAN=Y if you want to ensure that requests to certain services are processed in transaction mode.)

    In releases prior to Tuxedo 11.1.1.2.0, it was necessary to set the TUXWA4ORACLE environment variable for this automatic reconnection to work when using Tuxedo with Oracle Database. (This was due to different interpretations of the XA standard back when BEA and Oracle were separate companies.) Starting with Release 11.1.1.2.0, it is no longer necessary to set TUXWA4ORACLE when using Oracle Database with Tuxedo.

    There are also special considerations when using Tuxedo with Oracle Real Application Clusters, as described at http://docs.oracle.com/cd/E35855_01/tuxedo/docs12c/ads/adorac.html .

    The other way to use Tuxedo with a database is to not use the XA interface and to manage connections to the database in the application. If this is done, then the application needs code to connect, disconnect, and reconnect to the database and to commit or rollback work where appropriate. If the XA interface is not used, then Tuxedo will not have any involvement with connection or reconnection to the database.

    Regards,
    Ed
  • 2. Re: Auto Reconnection of Oracle Tuxedo 11.1.1.2.0, 64-bit to Oracle Data Base
    985149 Newbie
    Currently Being Moderated
    Hi ED,

    Thanks for your Reply...

    I Implemented the solution given by you...
    Still it didn't resolve my issue.

    I will give you just a brief what i have done till now.

    After your last reply i removed all of the EXEC COMMIT WORK; and EXEC ROLLBACK WORK; from our applications
    and recompiled again. In the *INTERFACES sections changed AUTOTRAN=N to AUTOTRAN=Y.

    Now while trying to boot up the servers in the Tuxedo it is booting up to first Routing server from the *SERVERS section and after that it is getting stuck. 

    Just wanted make you my goal is to run our applications with out having reconnect code from our applications.
    Tuxedo should automatically reconnect to Oracle DB once connect is lost.

    Appreciating your help on this issue.
    Thanks...


    *SERVERS
    "Routing" SRVGRP="ORA_GRP" SRVID=20
    CLOPT="-e ./trc/RoutingServer.trc -o ./trc/SYS_ERROR_LOG"
    RQPERM=0666 REPLYQ=N RPPERM=0666 MIN=1 MAX=4 CONV=N
    SYSTEM_ACCESS=FASTPATH
    MAXGEN=50 GRACE=86400 RESTART=Y
    "Routing" SRVGRP="ORA_GRP1" SRVID=20
    CLOPT="-e ./trc/RoutingServer.trc -o ./trc/SYS_ERROR_LOG"
    RQPERM=0666 REPLYQ=N RPPERM=0666 MIN=1 MAX=4 CONV=N
    SYSTEM_ACCESS=FASTPATH
    MAXGEN=50 GRACE=86400 RESTART=Y
    MINDISPATCHTHREADS=0 MAXDISPATCHTHREADS=1 THREADSTACKSIZE=0
    SICACHEENTRIESMAX="500"

    *INTERFACES
    "IDL:com.lhcargo.ebooking/Routing/RouteSelector:1.0"
    LOAD=50 PRIO=50
    TRANTIME=240
    AUTOTRAN=Y
    TIMEOUT=240

    Rgds,
    Plaban
  • 3. Re: Auto Reconnection of Oracle Tuxedo 11.1.1.2.0, 64-bit to Oracle Data Base
    Todd Little Expert
    Currently Being Moderated
    Hi Plaban,

    What do you mean it is getting stuck? Do you have a TPSVRINIT() function that is trying to do something that might hang?

    As Ed said, if a Tuxedo server is running in transactional mode, i.e., the server is part of a transaction either due to the transaction having been started by one of the callers higher up in the call chain, or by enabling AUTOTRAN, then Tuxedo will (actually MUST) control the connection to the database. At the beginning of any transactions service, Tuxedo will either start a new transaction with the resource manager, or attempt to join an existing transaction. If the connection to the database has failed, Tuxedo will get an error back from the database, and then try to reopen the database connection. All of this is mostly transparent to the application, although if the failure occurs during the execution of a service, then the client database calls may return errors that the application can either handle, or simply return an error as part of tpreturn().

    Regards,
    Todd Little
    Oracle Tuxedo Chief Architect
  • 4. Re: Auto Reconnection of Oracle Tuxedo 11.1.1.2.0, 64-bit to Oracle Data Base
    770343 Newbie
    Currently Being Moderated
    Hi,

    I am taking over this issue from Plaban as he is currently sick.
    Our application uses AUTOTRAN=N for all the interfaces.
    Is there any chance Tuxedo can handle auto reconnection to Oracle DB in such cases ? If not, please let us know any alternate solution

    Best Regards
    Sunil
  • 5. Re: Auto Reconnection of Oracle Tuxedo 11.1.1.2.0, 64-bit to Oracle Data Base
    Todd Little Expert
    Currently Being Moderated
    Hi Sunil,

    If your servers aren't transactional, meaning their services don't run in the context of a distributed transaction, Tuxedo isn't even aware of the database connection. The only thing Tuxedo really knows about is a resource manager (RM) such as a database and the XA switch that the RM provides that allows Tuxedo to call specific XA functions inside the RM's libraries. But these calls to the RM's libraries only occur if Tuxedo is managing a transaction for the server. So if AUTOTRAN=N and the server is called by a client or other server not in the context of a transaction, Tuxedo won't know anything about the connection, the state of the connection, or pretty much anything else about the RM.

    You could try enabling Transparent Application Failover (TAF) if you aren't using transactions as TAF should allow your database connection to failover to another database instance. If you need even more control than that, you could register an OCI callback to get notified when a connection is lost and then try to reconnect as well. So their are options.

    Regards,
    Todd Little
    Oracle Tuxedo Chief Architect
  • 6. Re: Auto Reconnection of Oracle Tuxedo 11.1.1.2.0, 64-bit to Oracle Data Base
    Per Lindström Explorer
    Currently Being Moderated

    As far as my tests show, if the database is down when you tmboot your Tuxedo application (or machine, or server group), you're basically out of luck. The TMS seems to require that the database is available during tpsvrinit().

     

    As reasonable as this may be (I guess it's related to transaction recovery and other Complicated Stuff you'd like to do during startup), it still undermines the notion of Tuxedo being [completely] "self-healing" with regards to database connection errors.

     

    We have a tmboot wrapper script where we test the database for basic connectivity before actually doing tmboot. I've hoped to be able to get rid of that wrapper script, but I guess I'll better keep it...

     

    Just my SEK 0,02 (that would amount to some 10 cents in American currency, actually :-))

    /Per

  • 7. Re: Auto Reconnection of Oracle Tuxedo 11.1.1.2.0, 64-bit to Oracle Data Base
    Todd Little Expert
    Currently Being Moderated

    Hi Per,

     

    I guess the question is what should a TMS do if it can't connect at boot time?  Until the TMS has a connection to the RM, it can't process any transactions.  So allowing the group to boot with TMS servers that can't do transactions seems a little pointless.  What would you like the TMS and tmboot to do if the RM is unavailable?

     

    Regards,

    Todd Little

    Oracle Tuxedo Chief Architect

  • 8. Re: Auto Reconnection of Oracle Tuxedo 11.1.1.2.0, 64-bit to Oracle Data Base
    Per Lindström Explorer
    Currently Being Moderated

    Hi Todd,

     

    I guess I would like it to just sort of await that the database becomes available... what happens if the database goes belly-up 1 second after tmboot completes (when it is supposed to be a recoverable situation)? In my mind, it would be nice to be able to deal with the situation where the database (which is operated by Mr Murphy himself, by the way ) crashes 1 second before tmboot, in just the same way.

     

    But I guess there are things to do during startup (check the TLOG and initiate some possible in-doubt tx cleanup?) that you want to get off the table before starting any new business. Would it be possible to defer that processing until the first actual transaction is being initiated in the case of a "bad startup situation"?

     

    Best regards.

    /Per

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points