When a HiRDB parallel server configuration is used, the front-end server must be connected to a back-end server to start a transaction. Consequently, in a system with a high volume of traffic that requires high throughput, this connection process can become a performance bottleneck. When the BES connection holding facility is used, the connection between the front-end server and a back-end server is not terminated when a transaction terminates. This means that if a subsequent transaction will use the same back-end server, no connection processing is needed between the front-end server and the back-end server. In other words, the BES connection holding facility eliminates a performance bottleneck by eliminated the need for connection processing between the front-end server and a back-end server.
The following figure shows the transaction flow when the BES connection holding facility is used.
Figure E-1 Transaction flow when the BES connection holding facility is used
- Reference note
- Although the BES connection holding facility also reduces the number of processes for disconnecting the front-end server from a back-end server, this does not have much effect on system performance.
- The BES connection holding facility cannot hold the connection between the front-end server and the dictionary server. When a transaction involving the dictionary server is terminated, the connection between the front-end server and the dictionary server is terminated.
You must set up the following environment to use the BES connection holding facility:
- Set the BES connection holding facility
- Set a BES connection holding period
- Set a maximum client wait time
- Set the number of back-end server processes
(a) Setting the BES connection holding facility
To use the BES connection holding facility, you must specify either (or both) of the following operands:
- pd_bes_connection_hold operand
- PDBESCONHOLD operand in a client environment definition
When the pd_bes_connection_hold operand is specified, the BES connection holding facility is applied to all UAPs. When the PDBESCONHOLD operand of a client environment definition is specified, the BES connection holding facility is applied only to UAPs executed from the client for which the PDBESCONHOLD operand was specified. The PDBESCONHOLD operand has higher priority than the pd_bes_connection_hold operand. Operand combinations are explained below.
- When pd_bes_connection_hold = Y is specified
The BES connection holding facility is applied to all UAPs.
- When PDBESCONHOLD = YES is specified
The BES connection holding facility is applied only to UAPs executed from the client for which the operand is specified.
- When pd_bes_connection_hold = Y and PDBESCONHOLD = NO are both specified
The BES connection holding facility is applied to all UAPs except for UAPs executed from a client for which PDBESCONHOLD = NO is specified.
Specify how long the BES connection is to be held open after a transaction terminates. When the specified BES connection hold time expires, the connection between the front-end server and the back-end server will be terminated when the next transaction that is executed terminates.
- How the BES connection holding period is measured
- Measurement of the BES connection holding period starts and ends as explained below:
- Measurement starting point: When transaction processing terminates
- Measurement ending point: When the next transaction's processing starts
- The following figure shows how the BES connection holding period is measured and the processing performed by HiRDB.
Figure E-2 Measurement of the BES connection holding period and processing by HiRDB
- Explanation
- Because interval [1] is within the BES connection holding period, the connection between the FES and BES1 remains open.
- Because interval [2] exceeds the BES connection holding period, the connection between the FES and BES2 will be terminated when the next transaction (transaction 3) terminates. When the next transaction to be executed after that (transaction 4) starts, the FES and BES2 must be connected anew.
- Notes
- Note that the connection between the front-end server and a back-end server does not terminate as soon as the BES connection holding period expires. The following summarizes the processing performed by HiRDB in the event the BES connection holding period expires:
- At the point when the BES connection holding period expires
HiRDB does not take any action.
- When a transaction starts
Because the connection between the front-end server and the back-end server is still being held, no processing is required to connect the front-end server to the back-end server.
- When this transaction terminates
Terminates the connection between the front-end server and the back-end server.
- When the next transaction starts
Connects the front-end server to the back-end server.
- Specification guidelines for the BES connection holding period
- For a system in which the UAP connection period is brief, set the BES connection holding period to 0.
- For a system that is always connected or in which the UAP connection period is prolonged, do not specify the BES connect hold period; instead, use the default value (1 second).
- Operation when 0 is specified as the BES connection holding period
- When 0 is specified as the BES connection holding period, time is not monitored and the connection between the front-end server and the back-end server is held open indefinitely. However, such a connection will be terminated in the cases explained in (4)(b) Cases in which a connection hold is canceled.
- Specifying the BES connection holding period
- To specify the BES connection holding period, you specify either (or both) of the following operands:
- The BES connection holding period specified with the pd_bes_conn_hold_trn_interval operand is applied to all UAPs. In contrast, the BES connection holding period specified with the PDBESCONHTI operand in a client environment definition is applied only to UAPs executed from the client for which the PDBESCONHTI operand was specified. The PDBESCONHTI operand has higher priority than the pd_bes_conn_hold_trn_interval operand. The following explains the operand combinations:
- When pd_bes_conn_hold_trn_interval = 10 is specified
- The BES connection holding period is 10 seconds for all UAPs.
- When PDBESCONHTI = 10 is specified
- The BES connection holding period is 10 seconds for UAPs executed from the client for which this operand is specified.
- When pd_bes_conn_hold_trn_interval = 10 and PDBESCONHTI = 20 are specified
- The BES connection holding period is 20 seconds for UAPs executed from the client for which the PDBESCONHTI operand is specified and 10 seconds for all other UAPs.
(c) Setting the maximum client wait time
If the unit of a back-end server for which connection is being held terminates abnormally, the transaction that is executed next by that back-end server might end in error or go into no-response status. If the transaction queuing facility is being used, the retry processing based on pd_ha_trn_restart_retry_time might not be executed, ending in error or going into no-response status (the same holds true for planned system switchover).
Therefore, to be prepared for the possibility that a transaction might end in error or go into no-response status, specify the maximum wait time in the PDCWAITTIME operand of the client environment definition.
If there is no response from a transaction within the time specified by the PDCWAITTIME operand, the transaction is canceled.
(d) Setting the number of back-end server processes
To use the BES connection holding facility, you should set the number of individual back-end servers to be greater than the total number of front-end servers in the system. To do so, specify values for the system definition operands so that the following condition is satisfied:
- value-of-pd_max_bes_process-operand
- value-of-pd_max_users-operand number-of-front-end-servers
If this condition is not satisfied, a shortage might occur in the number of available back-end server processes, and, as a result, the message queue monitoring facility might cause HiRDB (or unit for a HiRDB parallel server configuration) to terminate abnormally or an SQL error might occur.
To execute utilities while UAPs are running, the number of back-end server processes you specify must also include the number needed by the utilities.
(a) Do not use for definition SQLs
Do not use the BES connection holding facility for a UAP that executes a definition SQL. If the facility is used for such a UAP, connection between the front-end server and back-end server might occur simultaneously with connection between the dictionary server and the back-end server, and, as a result, a shortage might occur in the number of available back-end server processes, causing an SQL error. You can prevent this situation from occurring by specifying NO in the PDBESCONHOLD operand in the client environment definition of any UAP that executes a definition SQL.
(b) Cases in which a connection hold is canceled
Even when the BES connection holding facility is used, the connection between the front-end server and a back-end server is terminated unconditionally in the following cases:
- The front-end server is disconnected from the client by the DISCONNECT statement (xa_close if the HiRDB XA library is used), or because the time specified in PDCWAITTIME has been exceeded.
- Rollback (including internal rollback) occurs.
- The facility for monitoring the memory size of server processes determines that the memory usage upper limit has been exceeded.
- A large amount of memory is used internally.
- The pdpfresh command (without the -f option specified) is executed.
- The cursor of a holdable cursor is closed.
- The SET SESSION AUTHORIZATION statement is executed.
(c) Connection might not be terminated even when the BES connection holding period has expired
In the following cases, the connection between the front-end server and back-end server is not terminated even though the BES connection holding period has expired:
- A holdable cursor is used
- A local buffer specified in the UAP environment definition is used
All Rights Reserved. Copyright (C) 2011, 2015, Hitachi, Ltd.