The number of database connections that InterChange Server uses varies greatly, based on usage patterns:
Table 11 summarizes the way that InterChange Server uses
databases.
Table 11. InterChange Server use of databases
Environment | Database use | Reads | Writes |
---|---|---|---|
Run time | Repository service | × |
|
| Event management service | × | × |
| Transaction service | × | × |
| Flow Monitoring service | × | × |
Configuration time | System Manager | × | × |
Design time | Process Designer | × | × |
You can limit the number of DBMS connections that InterChange Server uses by configuring the MAX_CONNECTIONS parameter in the InterchangeSystem.cfg file. You can use this parameter to limit connections whether the server is using one data source or multiple data sources.
By default, InterChange Server opens connections when necessary and times them out when they are idle. The server also manages the sharing of connection resources among services that use the same database.
There is no maximum number of connections, unless you specify a number using the MAX_CONNECTIONS parameter. However, a connection limit may exist in the DBMS server configuration. For example, the Desktop version of SQL Server may allow unlimited connections, but the Standard version of SQL Server may have a connection limit based on the licensing agreement. By default, many DBMS servers have low default connection limits. Before setting the connection limit for InterChange Server, check the DBMS configuration.
To control the number of DBMS connections that InterChange Server uses, edit the InterChange.cfg file. Enter a value for MAX_CONNECTIONS in the DB_CONNECTIVITY section. This value governs the total number of DBMS connections that InterChange Server can have at one time.
The following configuration file entry limits InterChange Server connections to 20:
[DB_CONNECTIVITY] MAX_CONNECTIONS = 20
If InterChange Server needs a connection but has the maximum number open, it tries to free up an existing connection, using a least-recent-use algorithm.
Setting the MAX_CONNECTIONS parameter in the DB_CONNECTIVITY section of the InterChangeSystem.cfg file applies a connection constraint across all data sources. That parameter is not appropriate for use when the work load is partitioned across multiple data sources because you might want to set connection restraints on one data source and not on another. In addition, because InterChange Server does not take over connections across data sources, one service can use all the allotted connections, leaving none for other services.
In a partitioned environment, you can set constraints on connections to particular data sources by limiting the connections that each service makes. For example, if the repository, event management service, transaction service, and flow monitoring service use separate data sources, you can specify a different maximum for each data source, as follows:
DB2 |
---|
[EVENT_MANAGEMENT] DATA_SOURCE_NAME = jdbc:db2:EventsDB MAX_CONNECTIONS = 20 [TRANSACTIONS] DATA_SOURCE_NAME = jdbc:db2:TransDB MAX_CONNECTIONS = 30 [REPOSITORY] DATA_SOURCE_NAME = jdbc:db2:ReposDB MAX_CONNECTIONS = 50 [FLOW_MONITORING] DATA_SOURCE_NAME = jdbc:db2:FlowDB MAX_CONNECTIONS = 20 |
Oracle |
---|
[EVENT_MANAGEMENT] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:oracle://@server1:1521;SID=EventsDB MAX_CONNECTIONS = 20 [TRANSACTIONS] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:oracle://@server2:1521;SID=TransDB MAX_CONNECTIONS = 30 [REPOSITORY] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:oracle://@server3:1521;SID=ReposDB MAX_CONNECTIONS = 50 [FLOW_MONITORING] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:oracle://@server3:1521;SID=FlowDB MAX_CONNECTIONS = 20 |
You can set the MAX_CONNECTIONS parameter for one service without setting it for the others.