8.6.1 Points where a timeout can be set

In the systems used for executing J2EE applications, you can set up timeouts at the points shown in the following figure. In the following figure, a Web browser is used as the client. The points will differ when you integrate with a Web server, and when you send and receive requests directly to and from the J2EE server without going through a Web server.

Figure 8‒9: Points where a timeout can be set (for Web server integration)

If the client is an EJB client, replace the Web container with the EJB client. You can set the timeout ranging from the EJB client up to the database.

When sending and receiving requests directly to and from the J2EE server without going through the Web server, this process does not apply to the Web server and the reverse proxy. For this reason, points 1 to 4 do not apply. The following figure shows the points where a timeout can be set when sending and receiving requests directly to and from the J2EE server.

Figure 8‒10: Points where a timeout can be set (for direct requests to and from J2EE server)

The timeout specified at each point has a specific use that is described in the table below:

Table 8‒25: Purpose of timeout set at each point and default timeout settings

Points	Type of timeout	Primary usage
1	Timeout set in the Web server for receiving the request from the client and sending the data to the client	Detecting failures in the communication path or the Web server
2	Connection timeout specified on the reverse proxy side in the processing for sending requests to the Web container	Detecting failures in the communication path or the Web container
3	Request header and request body transmission timeout specified on the reverse proxy side in the processing for sending requests to the Web container	Detecting failures in the communication path or the Web container
4	Timeout for data reception from the Web container set on the reverse proxy side	Detecting failures in business processing (such as infinite loop and deadlock) of the J2EE server or the communication path
5	Timeout for data reception from the reverse proxy or Web client set on the Web container side	Detecting failures in the communication path, failures in the Web server, or access from unauthorized clients
6	Timeout set in the Web application for the method execution time	Detecting failures in business processing (such as infinite loop and deadlock) of the J2EE server
7	Timeout set in the EJB client for remotely invoking the Enterprise Bean (RMI-IIOP communication) and for invoking the JNDI Naming Service	Detecting failures in business processing (such as infinite loop and deadlocks) of the J2EE server or the communication path
8#	Timeout set up in the EJB client for invoking the Enterprise Bean from CTM	Detecting failures in business processing (such as infinite loop and deadlocks) of the J2EE server or the communication path
9	Timeout set in the EJB for the method execution time	Detecting failures in business processing (such as infinite loop and deadlock) of the J2EE server
10	Timeout set in the EJB container for the database transaction	Detecting failures in database server (such as server is down or a deadlock has occurred) or preventing the extended exclusive use of the resources
11	Timeout set in DB Connector for acquiring a connection	Detecting errors when a connection is acquired (communication path errors or resource depletion)
12	Database timeout	Detecting failures in database server (such as server is down or a deadlock has occurred) or preventing the extended exclusive use of the resources
13	Timeout for sending a response to the reverse proxy or Web client set on the Web container side	Detecting failures in the communication path and failures in the Web server

The basic guidelines for setting the above timeouts are as follows:

• The general rule for setting a timeout value is that the closer a point is from the invocation origin (Web client or EJB client), the higher the timeout value. It is, therefore, recommended to use the following relationship for setting the timeout.

  • Point 1 < Point 5

  • Point 4 > Point 6 > Point 7

  • Point 7 = Point 8 > Point 9 > Point 10

  • Point 10 > Point 11

  • Point 9 > Point 12

  • Point 1 < Point 13

• When setting the timeout values for points 4, 7, 10 and 12, first check the amount of time normally taken by the invocation process, and then calculate and set the timeout value for each invocation process (business).

The points 1 to 13 can be divided into the following three categories depending on their location in the system:

• For more information on points (1 to 6, and 13) that need to be considered in a Web front-end system.

  For details, see 8.6.2 Setting the timeout in a Web front-end system.

• Points (7 to 9) that need to be considered in the back system

  For details, see 8.6.3 Setting a timeout in the back-end system.

• Point (10 to 12) that need to be considered during database connection

  This point needs to be further classified into a transaction timeout, DB Connector timeout, and database timeout. For details, see 8.6.4 Setting the transaction timeout and 8.6.6 Setting the database timeout.

For details about the settings of each point, see 8.6.8 Tuning parameters for setting the timeout.

Reference note

The default values for each point are as follows:

Point	Default value
1	60 seconds
2	60 seconds
3	60 seconds
4	60 seconds
5	300 seconds
6	Not set. No timeout.
7	Not set. Continues to wait for response.
8	A value same as point 7 is automatically inherited and set up when the Enterprise Bean is invoked.
9	Not set. No timeout.
10	180 seconds
11	Differs according to the location of the timeout setup. A timeout in establishing a physical connection: 8 seconds A timeout in the request for connection during connection depletion: 30 seconds A timeout in detecting a connection error: 5 seconds
12	Differs according to the type of database and the location of timeout setting. For HiRDB Unlock waiting timeout: 180 seconds Response timeout: 0 seconds (The HiRDB client continues to wait until there is a response from the HiRDB server.) Request interval timeout: 600 seconds For Oracle (when global transaction is used) Unlock waiting timeout: 60 seconds For SQL Server Timeout in acquiring memory: -1 (For details about the operations when -1 is specified, see the SQL Server documentation) Unlock waiting timeout: -1 (Continues to wait until the lock is released) For XDM/RD E2 Unlock waiting timeout: None (timeout is not monitored) CPU timeout during SQL execution: 10 seconds SQL execution timeout: 0 seconds (timeout is not monitored) Transaction timeout: 600 seconds Response timeout: 0 seconds (The HiRDB client continues to wait until there is a response from the XDM/RD E2 server.)
13	300 seconds

To Page Top