Database connections

Databases contain business data that is written and accessed by deployed message flows. You must create connections from the integration node to the database by using ODBC or JDBC.

A database connection is a configuration file where you specify a database's physical details such as database type and version, and parameters to enable a JDBC connection from IBM® App Connect Enterprise Toolkit to the database.

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

The integration node 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 an integration node requires depends on the actions of the message flows that access the database. For each message flow thread, an integration node 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 integration node 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.

Linux platformWindows platformUNIX platformOn 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 are not released when the message flow becomes idle. These types of connections are only released in the following circumstances:

  • An error occurs, while accessing the database, that requires a new connection to be made.
  • The message flow is stopped.
  • The integration node is stopped.

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

  • An error occurs, while accessing the database, that requires a new connection to be made.
  • The message flow has been idle for 1 minute.
  • The message flow is stopped.
  • The integration node is stopped.

z/OS platformOn z/OS®, database connections are released if the database has not been accessed for 1 minute.

To change the default time of 1 minute after which a database connection for an idle message flow is released, use the following command:
mqsichangeproperties integration_node -e integration_server -o ComIbmDatabaseConnectionManager -n maxConnectionAge -v newValue
or the following command, to change the default time for all integration servers:
mqsichangeproperties integration_node -o ComIbmDatabaseConnectionManager -n maxConnectionAge -v newValue
where maxConnectionAge is specified in seconds. If maxConnectionAge is set to option -1, database connections are never released until the integration server or integration node is stopped.

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 integration node 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).

Use the maxConnectionUseCount configuration parameter to release an ODBC connection to the database after a specified number of transactions on a thread is reached. To activate this function, set maxConnectionUseCount to a value that is greater than zero.

maxConnectionUseCount is monitored on a per thread basis. For example, if you have additional instances of a message flow, meaning that you have multiple threads running in parallel, the connection to the database is released only on those threads that reach the value specified in maxConnectionUseCount.

For an integration server that is managed by an integration node, you can set the value of maxConnectionUseCount by using the mqsichangeproperties command. For example, to reset the ODBC connection after every 100 transactions, including commit and rollback processes, for each datasource connection on a thread, issue the following command:
mqsichangeproperties integration_node -e integration_server -o ComIbmDatabaseConnectionManager -n maxConnectionUseCount -v 100

Restart the integration server for the update to take effect.

Use the mqsireportproperties command to discover the current number of completed transactions on each datasource connection. This value is reported in the transactionCount field. For example:
mqsireportproperties integration_node -e integration_server -o ComIbmDatabaseConnectionManager -r

                    createTime='2020-08-11 04:50:15.285704 (1599799815)'
                    lastExecuteTime='2020-08-11 04:50:40.404019 (1599799840)'
                    text='INSERT INTO TEST VALUES (?)'
For an independent integration server, you can update the value of maxConnectionUseCount in the ResourceManagers section of the server.conf.yaml file. For example:
     maxConnectionUseCount: '100'

Restart the integration server for the update to take effect.

When the release function that is activated when maxConnectionUseCount is set to a value greater than zero, connection release is prompted when whichever of the values in maxConnectionAge or maxConnectionUseCount is reached first. To serve as an example, consider a scenario where maxConnectionUseCount is set to 100, and maxConnectionAge is set to 60. In such a scenario:
  • If 100 transactions are processed within 30 seconds of the creation of an ODBC connection, the ODBC connection is released immediately after the number of transactions reaches 100. A new ODBC connection will be established on the next message.
  • If 10, say, transactions are processed within 30 seconds of the creation of an ODBC connection, and for next 60 seconds, or more, no messages are processed on this ODBC connection, the value specified in maxConnectionAge is reached and the connection is released.
  • If 10, say, transactions are processed every 30 seconds, and the connection is never idle for more than 60 seconds, the ODBC connection is released after the total transaction count reaches 100, which, in this example, is after 300 seconds.
Note: The connectionAge field that is returned as part of the output from the mqsireportproperties command is not a configurable property; it is a runtime metric that indicates the age of the connection. There is no relationship between connectionAge and maxConnectionAge. The value in connectionAge can exceed the value in maxConnectionAge as seen in the example scenario description above where connectionAge would be 300 and maxConnectionAge is 60.

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 integration node reflect its current use of these resources. This situation allows the integration node 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.