Filter
Top Products
With this implementation, the database reports any idle connections to the system,
which is the expected behavior. JDBC properties can be tuned in the
jdbc.properties file to delete idle connections and minimize usage.
Note: Override the JDBC properties in the customer_overrides.properties file. Do
not modify the jdbc.properties file directly. For more information about the
jdbc.properties file, see the properties file documentation.
Implementation of connection pooling
Each database pool is created with an initial number of connections, as defined by
the initsize property in the jdbc.properties file. As more connections are
required, Sterling B2B Integrator requests additional connections up to the
maximum number defined by the maxsize property. When Sterling B2B Integrator
finishes with a connection, the connection is returned to the pool of connections for
later use.
If Sterling B2B Integrator requires connections beyond the maximum size limit for
each database pool, and every pool is in use, Sterling B2B Integrator can request
new connections up to the value defined by the buffer_size property. Connections
in this “buffer range” (that is, beyond the number of connections that are defined
by the maxsize property) are created as needed, and deleted when the calling
process is completed. To detect this condition, search for warning messages such as
connections exceeded in the noapp.log file. Performance drops if Sterling B2B
Integrator runs in this range for a long time.
The buffer_max value is a hard maximum. When the number of connections that
are defined by buffer_max (maxsize + buffersize) is reached, additional requests
for connections are denied. An error is written to the logs that indicates that the
pool is exhausted and the attempt to create a new connection failed.
Summary
Each JVM can create connections for each of the pools that are defined in the
jdbc.properties file and configured in the customer_overrides.properties file.
Each pool grabs the initial number of connections (initsize) configured.
Because a pool requires additional connections beyond the initial size, it creates
new connections up to the maxsize limit for that pool. Connections that are created
with fewer than the maxsize are returned to that pool for reuse, thus improving
performance.
If a pool is using all the connections up to the maxsize limit, it creates a new
connection as needed within the buffer size limit. Connections beyond maxsize and
below the buffersize are not reused. Each connection is created when needed, and
deleted when no longer needed by the calling process. This method is expensive
and harms performance if Sterling B2B Integrator runs for continued amounts of
time in this state.
When the number of connections (maxsize + buffersize) is reached, new requests
for connections are refused.
You can now manage JDBC pools dynamically. For more information about
dynamically managing JDBC pools, see “Dynamically Manage JDBC Pools” on
page 20.
Performance Management 17