Overview
Timeouts are used to fine tune the transport behavior and need to be tailored to application specific needs. They determine when a transaction will fail or be sent to the store and forward queue, when the host is unreachable or cannot be reached within a reasonable amount of time.
If a transaction consistently takes 10 seconds to execute, but the transport Execution timeout parameter is set to 5 seconds, then the transaction will cause the transport to switch to store and forward mode, or be counted as failure if Store and Forward is not enabled.
Similarly, if it takes more than the Connection time to establish a connection to a host, the transport will switch to store and forward mode.
Parameter values for a Timeout tab
The following shows the example SAP transport and its
Timeout tab:
| Option | Description |
|---|---|
| Connection (sec) | Required. Defaults to 10
seconds. Specifies the length of time the system will try to connect to a target computer (where an associated database program or TCP application are running). If the connection is not made in the specified time period, an error message is sent to the exception log. Also, the State column on the Transports tab will indicate Down. If the transport has store and forward enabled, the State column will indicate Storeand Forward. |
| Execution
(sec) |
Required. Defaults to 5
seconds. Specifies how long the system should wait (once the connection is made) for a transaction to complete. The time value that you specify should be the outer limit for how long you expect a typical transaction to take using a transport. If store and forward is turned on, the Execution timeout value will also specify how long the Transaction Server will wait before attempting to either switch to store and forward mode (for a database Insert or Update operation and WebSphere MQ transports) or fail the transaction (for a Select operation or stored procedure with OUTPUT or INOUT parameters). In the case of a transport map with a Select operation or stored procedure with OUTPUT or INOUT parameters, if the execution fails due to a communication problem, the transaction is not put into store and forward mode. The reason is so that the value of a device variable on the controller is not changed at some future point in time when the connection to the database is restored. There can be any number of reasons for transactions to take a long time: The server is extremely busy at certain times of the day, the network has a disruption due to a pulled cable or a switch shutoff that may be temporary or permanent. About long execution timeouts: Keep in mind that specifying a long timeout can cause transactions to backup when triggers are firing at a very fast rate. In addition, some transports take longer to interact with the business enterprise target (such as a database Update operation or stored procedure calls). For these types of transports, it is better to create a separate transport for each transport type. This would prevent a slower transaction from blocking other transactions that are queued behind it. If a re-connection cannot be established, an error message is written to the exception log. The Failures column in the project tab for the specified trigger is incremented by the number of times the trigger failed. If store and forward is enabled (for database and WebSphere transports), the State column will indicate Store and Forward. MSSQL Transport The lock timeout on transactions to a MSSQL database is set to 90% of the value specified as the execution timeout. This means that if the time taken by a MSSQL transaction exceeds 90% of the execution timeout it will fail and the transport will process the transaction as if it had timed out. |
| Inactivity
(sec) |
Required. Defaults to 14,400
seconds. Specifies the maximum number of seconds of inactivity that the Transaction Server will wait before disconnecting from the host. |
The following Related Topics links pertain to tabs available from different transport type windows. For example, a transport window for a TCP transport has Timeout and Custom Payloads tabs; while a WebSphere MQ transport type has a Timeout, Store & Forward, Mapping Log, and Custom Payloads tabs.