The number of connections that InterChange Server uses varies greatly, based on usage patterns. The following examples show variations in the server's database use:
Table 29 summarizes the way that InterChange Server uses
databases.
Table 29. InterChange Server database use
Environment | Database Use | Reads | Writes |
---|---|---|---|
Runtime | Repository Service | × |
|
| Event Management Service | × | × |
| Transaction Service | × | × |
| Flow Monitoring Service | × | × |
Configuration time (System Manager) | Repository Service | × | × |
Design time (Process Designer, Business Object Designer, Map Designer, and Relationship Designer) | Repository Service | × | × |
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 a single 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 one, using the MAX_CONNECTIONS configuration parameter. However, a connection limit might exist in the DBMS server configuration.
To control the number of DBMS connections that InterChange Server uses, edit its configuration. For more information on how to configure InterChange Server, see Implementation Guide for WebSphere InterChange Server.
If InterChange Server needs a connection and already has the maximum number open, it tries to free up an existing connection, using a least-recently-used (LRU) algorithm.
The section, Setting up database connections describes how to set the MAX_CONNECTIONS parameter. This parameter enables you to ensure that the server uses only the number of connections that your database server can support.
Setting the MAX_CONNECTIONS parameter in the DB_CONNECTIVITY section applies a connection constraint across all data sources. That parameter is not appropriate for use when the workload 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. Suppose that the repository, event management service, transaction service, flow monitoring service, and security service are all using 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 [SECURITY] DATA_SOURCE_NAME = jdbc:db2:SecurDB 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://@server4:1521;SID=FlowDB MAX_CONNECTIONS = 20 [SECURITY] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:oracle://@server5:1521;SID=SecurDB MAX_CONNECTIONS = 20 |
You can set the MAX_CONNECTIONS parameter for one service, without setting it for the others.