IBM® Integration Bus manages JDBC connections in
the following ways:
- Non-pooled connections:
- IBM Integration Bus creates a JDBC connection
on demand for each message flow instance that requires one.
- Each JDBC connection is associated with the message flow instance
for which it was created. This association is maintained until the
connection is closed.
- Each JDBC connection that is idle for 60 seconds is closed, and
is no longer associated with a message flow instance.
- After a JDBC connection that was associated with a message flow
instance is closed, if the same message flow instance requires a JDBC
connection, IBM Integration Bus creates a new
JDBC connection on demand.
- Pooled connections:
- When a message flow instance requires a JDBC connection, IBM Integration Bus assigns an unused connection
from the pool.
- If all pooled JDBC connections are being used, and the maximum
pool size has not been reached, IBM Integration Bus creates
a new pooled JDBC connection. The maximum pool size is specified in
the maxConnectionPoolSize property of the JDBCProviders configurable service.
- Each pooled JDBC connection remains associated with a message
flow instance only for the processing of one input message.
- When a message flow instance completes the processing of an input
message, the association with a JDBC connection is removed, and the
JDBC connection is returned to the pool.
- Each pooled JDBC connection that is idle for 15 minutes is closed,
and is removed from the pool.
- Pooled JDBC connections are not applicable to the DatabaseRetrieve and DatabaseRoute nodes.
Using a JDBC connection pool enables you to scale database
access independently of the number of message flow threads.
The purpose of the JDBC connection pooling function in
IBM Integration Bus is to:
- Minimize the time and resource needed to create new connections,
by making pooled connections available for reuse by other message
flow threads when transactions complete.
- Enable greater control over the number of concurrent database
connections that can be in use at any time for a specific JDBC data
source.
Although these aims overlap with those of J2EE Java™ connection pooling, the priority is not to maximize the performance of individual JDBC calls to the database. In this respect, non-pooled JDBC connections might be more efficient in some scenarios.
You
can create a JDBC connection pool by setting the maxConnectionPoolSize property
of the JDBCProviders configurable service to a non-zero integer value.
The maxConnectionPoolSize property acts at the integration
server level to specify the maximum number of JDBC connection threads
that can be used. A value of zero defaults to the standard WebSphere® Message
Broker Version 8.0 behavior, where one JDBC connection
is created for each message flow thread.
All message flows within
an integration server that use the same JDBCProviders configurable
service also share a connection pool. You can monitor the behavior
of a JDBC connection pool by using broker resource statistics
The maxConnectionPoolSize property
is applicable to JDBC connections obtained using the getJDBCType4Connection() API
of the JavaCompute node, and to database operations in graphical data maps that
are called by the Mapping node.
Note:
The maxConnectionPoolSize property does not apply
to the JDBC connections used by the DatabaseRetrieve or DatabaseRoute nodes.