How DB2 calculates the wait time for timeouts

When a process requests a transaction lock that is unavailable, it waits for some period of time. DB2® determines the appropriate wait time by multiplying a timeout period by a multiplier based on the type of process.

The timeout period

Begin program-specific programming interface information.

DB2 calculates a timeout period from the values of the RESOURCE TIMEOUT and DEADLOCK TIME options.

For example, assume that the value of the DEADLOCK TIME option is 5 and the value of the RESOURCE TIMEOUT option is 18. You can use the following calculations to see how DB2 calculates a timeout period.

  1. Divide RESOURCE TIMEOUT by DEADLOCK TIME (18/5 = 3.6). IRLM limits the result of this division to 255.
  2. Round the result to the next largest integer (Round up 3.6 to 4).
  3. Multiply the DEADLOCK TIME by that integer (4 * 5 = 20).

The result, the timeout period (20 seconds), is always at least as large as the value of RESOURCE TIMEOUT (18 seconds), except when the RESOURCE TIMEOUT divided by DEADLOCK TIME exceeds 255.

The timeout multiplier

Requests from different types of processes wait for different multiples of the timeout period according to the timeout multiplier. In a data sharing environment, you can add another multiplier to those processes to wait for retained locks.

In some cases, you can modify the multiplier value. The following table indicates the multiplier value by type of process, and whether you can change it.

Table 1. Timeout multiplier by type
Type Multiplier1 Modifiable?
IMS™ MPP, IMS Fast Path Message Processing, CICS®, QMF™, CAF, TSO batch and online, RRSAF, global transactions 1 No
IMS BMPs 4 Yes
IMS DL/I batch 6 Yes
IMS Fast Path Non-message processing 6 No
BIND subcommand processing 3 No
STOP DATABASE command processing 10 No
Utilities 6 Yes
Retained locks for all types 0 Yes
Note:
  1. If the transaction occurs on a table space that is not logged, the timeout multiplier is either three or the current timeout multiplier for the thread, whichever is greater.

Changing the multiplier for IMS BMP and DL/I batch

You can modify the multipliers for IMS BMP and DL/I batch by modifying the following subsystem parameters on installation panel DSNTIPI:
IMS BMP TIMEOUT
The timeout multiplier for IMS BMP connections. A value from 1 to 254 is acceptable. The default is 4.
DL/I BATCH TIMEOUT
The timeout multiplier for IMS DL/I batch connections. A value from 1 to 254 is acceptable. The default is 6.

Additional multiplier for retained lock

For data sharing, you can specify an additional timeout multiplier to be applied to the connection's normal timeout multiplier. This multiplier is used when the connection is waiting for a retained lock, which is a lock held by a failed member of a data sharing group. A zero means don't wait for retained locks.

The scanning schedule

The following figure illustrates the following example of scanning to detect a timeout:

  • DEADLOCK TIME is set to 5 seconds.
  • RESOURCE TIMEOUT was chosen to be 18 seconds. Therefore, the timeout period is 20 seconds.
  • A bind operation starts 4 seconds before the next scan. The operation multiplier for a bind operation is 3.
Figure 1. An example of scanning for timeout
Begin figure description. A timeline arrow from left to right with start and end times (sec.) for timeout scan events: BIND (0-64); grace (4-9); timeout (9-20); deadlock (9-14) End figure description.

The scans proceed through the following steps:

  1. A scan starts 4 seconds after the bind operation requests a lock. As determined by the DEADLOCK TIME, scans occur every 5 seconds. The first scan in the example detects that the operation is inactive.
  2. IRLM allows at least one full interval of DEADLOCK TIME as a "grace period" for an inactive process. After that, its lock request is judged to be waiting. At 9 seconds, the second scan detects that the bind operation is waiting.
  3. The bind operation continues to wait for a multiple of the timeout period. In the example, the multiplier is 3 and the timeout period is 20 seconds. The bind operation continues to wait for 60 seconds longer.
  4. The scan that starts 64 seconds after the bind operation detects that the process has timed out.

Consequently, an operation can remain inactive for longer than the value of RESOURCE TIMEOUT.

If you are in a data sharing environment, the deadlock and timeout detection process is longer than that for non-data-sharing systems.

You should carefully consider the length of inaction time when choosing your own values of DEADLOCK TIME and RESOURCE TIMEOUT.

End program-specific programming interface information.