Timers define a limit to the amount of time that is required for
a specific operation to complete. The type of operation a timer controls determines
when the time period, that is set for that timer, starts to elapse.
Most timers have a default value that defines a reasonable time
period, during which a particular operation should complete. When the time
limit specified for the timer elapses, the product takes one of the following
actions:
- Sends a minor code to the client if the time limit elapses before the
client request is dispatched to a servant.
- Abnormally ends the servant with an EC3 ABEND if the time limit elapses
while the client request is being processed by an application component running
in the servant.
In this situation all of the threads in this servant are
terminated. The servant is also terminated to prevent the application from
holding resources, and thereby preventing other requests from using these
resources. After the servant is terminated, workload management (WLM) starts
a new servant to take the place of the servant that was terminated.
Avoid trouble: The total transaction lifetime timeout and
the maximum transaction timeout have grace periods beyond the timeout value
specified of approximately four minutes. This extended time period must elapse
before an ABEND occurs.
gotcha
Different types of timers might reach their time limits simultaneously,
because the operations they control might overlap to a certain degree. For
example, suppose the application server receives an IIOP client request that
is processed by an application component that uses transaction support. In
this case, both of the following timers count down simultaneously:
- control_region_wlm_dispatch_timeout, which limits both the amount of
time a client request waits on the WLM queue, as well as the time required
for the application component to process the request
- transaction_defaultTimeout, which limits the amount of time the controller
waits for a transaction to be either committed or rolled back
These timers overlap only for the time during which the transaction
is processed. To determine which timer cause the error, you can use the symptoms-
specific minor codes or EC3 abend reason codes.
To determine the occurrence
of a timeout as quickly as possible and to prevent further resource locking,
WebSphere Application Server prevents further transactional work on the transactional
path where the timeout condition has taken place. This applies equally to
attempting to perform work under the current transaction context and to attempting
to perform work under a different transactional context.
The timers
that are used to control processing behavior can be classified into five general
types. These general types, and the operations that they control, are summarized
in the following table.
General
type |
Timer
processing |
Timeout
symptoms |
Input |
Input
timers define limits for receiving a complete request; the countdown starts
when a connection to the J2EE server is established. The communication protocol
(HTTP, HTTPS) determines the timer used for the request. |
The
session is closed. |
Session |
Session
timers define limits for the use of session connections. These timers start
the countdown as soon as a session becomes idle. |
The
session is closed. |
WLM
dispatch |
Dispatch
timers control how long a complete client request waits to be dispatched in
a servant region for processing. The countdown starts when the controller
places the request on the WLM queue. Depending on the specific timer, the
time limit can include not only wait time on the WLM queue, but also the time
required for processing a response to the client request. |
Message
BBOO0232W and an EC3 ABEND in the servant (region), with one of these accompanying
reason codes:
- 04130003
- 04130004
- 04130006
|
Transaction |
Transaction
timers define how long:
- An application or controller waits for one transaction to complete. The
countdown starts when the container starts a transaction on behalf of the
application component.
- A controller attempts to recover in-doubt transactions during peer restart
and recovery mode.
|
- Message BBOT0003W or BBOO0232W
- An EC3 ABEND in the servant (region), with one of these accompanying
reason codes:
|
Output |
Output
timers define how long a controller waits to receive output for a client request.
The countdown starts when the client request is dispatched to the servant
region for processing. The communication protocol (HTTP or HTTPS) determines
the timer used for the request. |
Message
BBOO0232W and an EC3 ABEND in the servant (region), with reason code 04130007 |
|