The parameters in the DB_CONNECTIVITY section of the file govern the InterChange Server overall interactions with the database management system (DBMS).
The number of simultaneous connections InterChange Server can establish with DBMS servers. This parameter governs total number of ICS connections; similar parameters in the Event Management, Repository, and Transactions sections govern the number of connections allotted to specific services.
If you do not specify a value for this parameter, InterChange Server uses as many connections as it needs, timing them out after they become idle for the default time of 2 minutes or the time specified using the IDLE_TIMEOUT parameter.
Example: MAX_CONNECTIONS = 100
MAX_CONNECTIONS = 50
The maximum number of connection pools that InterChange Server creates for connections in the InterChange Server connection cache. The server currently creates one connection pool each for the repository, event management, transaction, flow monitoring (optional), and user registry (optional) databases.
When creating relationships between objects, you can specify the database to be used for storage of the relationship run time data. Connections to this database are managed in the same way as the Repository, Event Management, Transaction, and Flow Monitoring databases. If you specify more databases than the number used in the MAX_CONNECTION_POOLS parameter, an error message returns stating that the maximum number of connection pools has been reached.
Use the MAX_CONNECTION_POOLS parameter to accommodate the number of databases you are using. The minimum value is 8.
Example: MAX_CONNECTION_POOLS = 60
MAX_CONNECTION_POOLS = 50
The maximum number of times a transaction is tried before throwing an exception. The recommended retry count is 5. If the value is set to 0, a warning is returned by InterChange Server at startup, and if a deadlock occurs, the transation is not retried. This can cause InterChange Server to shut down.
Use the DEADLOCK_RETRY_INTERVAL parameter to specify the maximum amount of time to wait between retries. The recommended time is 20 seconds.
MAX_DEADLOCK_RETRY_COUNT = 5
The maximum amount of time to wait between deadlocked retries. The recommended time is 20 seconds. Setting the retry time too high slows the system unnecessarily.
DEADLOCK_RETRY_INTERVAL = 20
Specifies the maximum number of times that the server will try to reconnect to the database after the connection is found to be broken. The recommended retry count is 3. If the value is set to 0, this is equivalent to switching off the database connectivity resilience.
Use the DB_CONNECT_INTERVAL parameter to specify the amount of time to wait between retries.
DB_CONNECT_RETRIES = 3
Specifies the amount of time to wait between database connection retries. The recommended time is 60 seconds. Setting the retry interval too high will slow the system down unnecessarily. Setting the retry interval too low might lead to ICS shutdowns for database connectivity issues.
DB_CONNECT_INTERVAL = 60
The maximum time a connection between InterChange Server and the DBMS server can be idle before the connection is disconnected. This parameter works with the MAX_CONNECTIONS parameter in that it frees up idle connections and returns them to the available connections cache.
If you do not specify a value for this parameter, InterChange Server uses
the default
of 2 minutes. The value you specify is in minutes.
Example: IDLE_TIMEOUT = 4
IDLE_TIMEOUT = 2
The output file for JDBC logging. The file is placed in the ProductDir\bin directory, unless you specify a full path.
If the parameter does not appear in the file, or if it is commented out,
logging does
not take place.
Example: JDBC_LOG = jdbc.out (in the ProductDir directory)
There is no default value for this parameter.
UNIX |
---|
You can use either Oracle Server, DB2 Server, or Microsoft SQL Server. The only compatible database servers on a UNIX machine are Oracle and DB2; however, you can run Microsoft SQL Server on a Windows machine with your InterChange Server on UNIX. |
Windows |
---|
You can use either Oracle Server, DB2 Server, or Microsoft SQL Server for your database server. |
Examples:
DBMS = ORACLE DBMS = DB2 DBMS = SQLSERVER
The name of the driver that supports the DBMS. The possible values
are listed in Table 19:
Table 19. Drivers used with supported DBMS types
DBMS type | Driver name | Driver class name |
---|---|---|
MS SQL Server | IBM-branded Type 4 Driver | com.ibm.crossworlds.jdbc. sqlserver.SQLServerDriver |
Oracle Server | IBM-branded Type 4 Driver | com.ibm.crossworlds.jdbc.
oracle.OracleDriver |
DB2 Server | DB2 JDBC type 2 driver | com.ibm.db2.jdbc.app.DB2Driver |