17.4.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 use an in-process HTTP server.

Figure 17‒2: 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.

A redirector will not be applicable when you use an in-process HTTP server, and therefore, a timeout will not be set up at points 2 to 5, and 13. The following figure shows the points where you can set up timeouts to use in-process HTTP servers:

Figure 17‒3: Points where timeouts can be set up (for in-process HTTP servers)

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

Table 17‒5: Purpose of timeout set at each point and default timeout settings
Points	Type of timeout	Primary usage
1	Timeout set in the server for receiving the request from the client and sending the data to the client	For Web server integration Detecting failures in the communication path or the Web server For in-process HTTP servers Detecting failures in the communication path, or access from an invalid client
2	Connection timeout specified in the redirector in the processes for sending the requests to the Web container	Detecting failures in the communication path or the Web container
3	Timeout for sending the request header and request body set in the redirector in the processes for sending the requests to the Web container	Detecting failures in the communication path or the Web container
4	Timeout set in the redirector for receiving data from the Web container	Detecting failures in business processing (such as infinite loop and deadlock) of the J2EE server or the communication path
5	Timeout set in the Web container for receiving data from the redirector	Detecting failures in the communication path or the Web server
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 set in the Web container for sending a response to the redirector	Detecting failures in the communication path or the redirector

#: This point exists only when you are using CTM. For a configuration in which CTM is not used, the range of point 7 extends from the time of execution of remote invocation of the EJB from the Web container to the EJB container, until the dispatch of execution result from the EJB container to the Web container.

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 17.4.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 in the manual uCosminexus Application Server System Design Guide.
Points (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 in the uCosminexus Application Server System Design Guide.

For details on settings at the each point, see 17.4.3 Tuning parameters for setting the timeout, or 8.6.8 Tuning parameters for setting the timeout in the uCosminexus Application Server System Design Guide.

Reference note

The default values for each point are as follows:

Point	Default value
1	300 seconds
2	30 seconds
3	100 seconds
4	3,600 seconds
5	600 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	600 seconds

To Page Top