Database connections

ODBC connections to databases are managed internally by the broker, and therefore any configurable connection pooling options that are available on the ODBC driver should not be used.

The broker requires a database connection for each data source name (DSN) that is referenced in the message flow, even if different DSNs resolve to the same physical database. If the message flow is operating in coordinated mode then a separate XA connection to each DSN participating in the globally coordinated flow is also required.

The number of connections to a database that a broker requires depends on the actions of the message flows that access the database. For each message flow thread, a broker that accesses a database makes one connection for each data source name (DSN). If a different node on the same thread uses the same DSN, the same connection is used, unless a different transaction mode is used, in which case another connection is required. For further information about transactions, see Database connections for coordinated message flows.

Normally, the broker makes the connections when it needs to use them in the message flow. However, in the case of connections to ESQL-based data sources, you can make the initial connection before a flow receives a message, and so remove any connection latency from the message processing. Set this option by selecting Connect before flow starts property on the data source node.

If the message flow contains a DatabaseInput node, at least one database connection remains open while the message flow is running.

On Linux, UNIX, and Windows systems, database connections are released under the following circumstances:

Database connections that have been started with the Connect before flow starts option selected, or database connections that are involved in Globally Coordinated (XA) transactions, are not released when the message flow becomes idle. These types of connections are only released in the following circumstances:

All other database connections remain open until one of the following events occurs:

On z/OS®, database connections for globally coordinated message flows are also released if the database has not been accessed for 1 minute.

mqsichangeproperties myBroker -e myIntegrationServer -o ComIbmDatabaseConnectionManager -n maxConnectionAge -v newValue

mqsichangeproperties myBroker -o ComIbmDatabaseConnectionManager -n maxConnectionAge -v newValue

If you are using DB2® for your database, the default action is to limit the number of concurrent connections to a database to the value of the maxappls configuration parameter. The default for maxappls is 40. If you believe that the connections that the broker might require exceeds the value for maxappls, increase this parameter and the associated maxagents parameter to new values based on your calculations.

For z/OS, the number of connections does not change when you use ODBC CAF (Call Attachment Facility) connections or RRSAF (Recoverable Resource Services Attachment Facility). For more information on the number of connections required, see You do not know how many database connections a broker requires.

If you are using another database, check the database documentation for information about connections and the limits or restrictions that might apply.

When a message flow is idle, the integration server periodically releases database connections that have not been started with the Connect before flow starts option. Therefore, connections held by the broker reflect its current use of these resources. This situation allows the broker to respond when a database quiesces, if the database manager supports quiescing. Not all databases support the quiesce function, and not all databases quiesce in the same way. Check your database documentation for information about database quiescing.