OPENINFO and SesTm (session time limit)

Question

Hi All
And thanks in advance.
We don't quite understand SesTm and it's behavior. (We have spent lots of time reading about it and still)
We have SesTm=60 (and transaction timeout set to 5 min) how come a call to the database last 10 min and only then return with "ORA-02049" ?
* "ORA-02049: timeout: distributed transaction waiting for lock"
1) Why the query didn't return after 60 sec with an error as SesTm=60 instructs ?
*May be we don't understand SesTm. (please advice)
2) Why the query didn't return after 5 min as the transaction timeout instructs ? (TMQFORWORD -t 300)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
EXTRA INFORMATION (OPTIONAL) documentation of SesTm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The SesTm definition:
" SesTm=session_time_limit
Specifies the maximum number of seconds allowed in a transaction between one service and the next, or between a service and the commit or rollback of the transaction, before the system aborts the transaction. For example, SesTM=15 indicates that the session idle time limit is 15 seconds.
For example, if the TPM uses remote procedure calls between the client and the servers, then SesTM applies to the time between the completion of one RPC and the initiation of the next RPC, or the tx_commit, or the tx_rollback.
The value of 0 indicates no limit. Entering a value of 0 is strongly discouraged. It might tie up resources for a long time if something goes wrong. Also, if a child process has SesTM=0, then the SesTM setting is not effective after the parent process is terminated ."
You can read more about OPENINFO here:
http://download-east.oracle.com/docs/cd/B19306_01/appdev.102/b14251/adfns_xa.htm#i1006488
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Regards
TechSgin
Edited by: TechSgin on May 6, 2010 2:09 PM
Edited by: TechSgin on May 6, 2010 2:42 PM

Answer 1

Hi,
timeouts can be tricky (see other threads in this forum for some elaborations on timeouts).
To be brief, always set SesTm to a higher value than your transaction timeout. Rationale: You'll want Tuxedo to take action first, not Oracle ("behind Tuxedo's back"). If Tuxedo takes action first, the transaction will be managed more predictably if more data sources are involved.
Now it gets even more complicated. The transaction timeout value does not really specify how long something is really going to last, only how long time we're ready to wait for it until we give up. The -t 300 parameter to TMQFORWARD really means that the transaction will be forced to be rolled back unless it completes in (some) 300 seconds (it's really 300 seconds + BLOCKTIME - 1 that gives the maximum time due to rounding issues).
Just because the client (TMQFORWARD in this case) gives up waiting for a reply, the server won't necessary give up trying to produce it. In fact, it will continue to try as hard as possible to finally deliver a result. Any DML operation after the transaction timeout will most probably fail, but the server might try a lot of them (and the one causing the timeout will generally have to complete first).
If you really want to terminate long-running transactions in the server you need to specify a SVCTIMEOUT for the service(s) in question. In this case, Tuxedo will kill (using SIGINT and/or SIGKILL) any process running a service that takes too long time. In this case you better configure the server (the potential "killee") with RESTART=Y and MAXGEN=x.
Hope this helps,
/Per