Timeout: Tuxedo kills the service but not the database connection

Question

Hi all,
I am experiencing some performance problems on my system due an efficient SQL and a Tuxedo improper timeout handling.
A service is using a "problematic" SQL (we will tune it but it's not the main problem). After 60 seconds from the execution, Tuxido kills the services for a timeout.
At this point I would like Tuxedo to notify DB2 database as well in order to stop processing the SQL. Instead the SQL continues running on the database (also if the service is killed) and this produce a gradual slow down of the performances.
In the UBBCONFIG, we are using a service configuration like the following timeout configuration:
.RESOURCES
SCANUINIT 5
SANITYSCAN 6
BLOCKTIME 12
.SERVICES
DEFAULT: SVCTIMEOUT=45
service1 SVCTIMEOUT=60 TRANTIME=60
service2 SVCTIMEOUT=60 TRANTIME=60
Note: not all the services are listed in the .SERVICES section and we are using the default NOTIFY as well as an OPENINFO.
Can you please help me in finding a configuration to kill both the services and the database?
Thanks in advance,
Benedetto

Answer 1

Hi Benedetto.
First of all, Tuxedo doesn't kill services, it kills servers. Your UBBCONFIG file specifies three timeouts, BLOCKTIME, SVCTIMEOUT, and TRANTIME.
BLOCKTIME specifies how long a Tuxedo API that needs a response will wait for that response. If the response isn't received in that period of time, Tuxedo will return TPETIME to the caller. As with any failure, if the request was part of a transaction, the transaction is marked rollback only. Note, this timeout does not affect the request, whether sitting in a server's IPC queue or currently executing in a server.
SVCTIMEOUT is a much more severe timeout and determines how long Tuxedo will allow a service implementation to execute. If a service implementation doesn't reply within the SVCTIMEOUT period, Tuxedo will issue an OS level KILL request to kill the process. If the server is marked restartable, Tuxedo will then try to restart the server assuming none of the restart limits have been reached. Killing the server causes the request to be lost within the server so the caller will stay blocked until BLOCKTIME is reached at which point the above actions will take place.
TRANTIME is the amount of time Tuxedo allows a transaction to remain active and viable. When this period expires, Tuxedo will mark the transaction as timed out with the only option being rollback. As well, Tuxedo aborts any API requests that would normally cause messaging to occur, i.e., making a tpcall() within a timed out transaction will fail without any attempt to call the service.
So in your case, the issue is partially that you have the values of your timeouts in somewhat reverse order. Typically we see BLOCKTIME being the smallest value, with TRANTIME typically larger than BLOCKTIME, and SVCTIMEOUT larger even still, although there are good reasons for exceptions to this guideline. Part of the reasoning behind this is that killing a server is a significant thing and its usually best to try and let the server complete whatever its doing, if if the work has been timed out either due to BLOCKTIME or TRANTIME, since the cost of killing and restarting a server is significant.
Tuxedo will notify the database of the transaction status when the application finally issues a tpcommit() or a tpabort() request, but not until then. Although, if SVCTIMEOUT is hit, then killing the server should cause the database connection to be lot.
If you could describe the behavior you are seeing and the relevant portions of your ULOG we can try to make some sense of what is happening.
Regards,
Todd Little
Oracle Tuxedo Chief Architect