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 :-))
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?
Oracle Tuxedo Chief Architect
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"?