Extend data source definitions, which consist of non-core
or custom properties, for DB2® data sources to add a greater
level of application flexibility when you are using the DB2 Universal
JDBC driver or DB2 Using IBM® JCC
driver. This capability is sometimes referred to
as heterogeneous pooling. Use this feature to configure a DB2 data
source in the application server with a core set of data source properties,
and defer to individual applications to define any custom or non-core
properties, like currentSchema or clientApplicationInformation, that
you want to be application specific. You can also use these extended
definitions to override any non-core or custom properties that are
already defined for the data source. In addition, this feature can
reduce the number of physical connections that the application server
uses by employing one connection pool between resources that connect
to the same data source.
Before you begin
You must be using a DB2 data source, and the data source
must be configured in the application server with one of the following
JDBC providers:
- DB2 Universal JDBC driver (Version 4.3.81 or
higher)
- DB2 Using IBM JCC
driver (Version 3.53.65 or higher)
About this task
Associate non-core properties with different resource references
for a data source, and configure your applications to take advantage
of these resource references to extend or override any non-core properties
for the data source. You can choose to define new non-core or custom
properties, or override any non-core properties that are already defined
for the data source.
Also, applications can share the same connection
pool in the application server, even though each application might
have its own unique set of data source properties. There might be
only one data source that is defined in the application server, and
therefore only one connection pool, but to individual applications
it would appear that there is more than one data source that is defined.
This can result in:
- Reduction in memory consumption by the application server. Data
source definitions will correspond to one connection pool, so there
are fewer objects in memory when compared with a data source definition
that corresponds to its own connection pool.
- Reduction in the number of open connections to the data source,
which can reduce the memory consumption by the data source. The application
server can reduce the number of idle connections by providing one
connection pool that corresponds to multiple data sources, providing
a more efficient use of connections.
- Avoidance of two-phase commit (XA) transactions in certain DB2 scenarios,
when your applications use the get/use/close connection pattern. The
application server can share connections between different resource
references that have same set of core properties, even if they have
different non-core properties, within the same transaction. This behavior
can avoid two-phase commit processing if the connection sharing leads
the application server to use one and only one physical connection.
Procedure
- Update the data source definitions for an application that
is already installed.
- Navigate to the panel to manage the resource references
for the application.
- Navigate to the panel for extended data source properties.
Click Extended properties... in the Target
Resource JNDI Name column. If the data source does not
support extended data source properties, you will receive an error
when you try to apply these changes.
- Add a data source definition that is specific to that
target resource. Click New, and
complete the required fields. You cannot modify the following data
source properties, which must be the same for all applications that
use this data source:
- accountingInterval
- dataSourceName
- databaseName
- kerberosServerPrincipal
- loginTimeout
- logWriter
- password
- pkList
- planName
- portNumber
- readOnly
- securityMechanism
- serverName
- user
- Optional: Configure two res-refs and the
isolation level in the ibm-ejb-jar-ext.xml
- Optional: To avoid two-phase commit transactions,
employ the get/use/close connection pattern. The get/use/close
pattern is when an application gets a connection from a data source
or connection factory and completes the current work within a single
method, and the application does not call another method until that
work is complete.
- Ensure that your applications use the get/use/close
connection pattern.
- Enable the application server to verify use of the get/use/close
connection pattern in applications, which will lead to the avoidance
of two-phase commit processing if the sharing leads to one and only
one physical connection being used.
- Click
- Select Optimize for get/use/close connection pattern
with heterogenous pooling. You will receive error messages
if you select this option and your applications do not use the get/use/close
connection pattern.
- Optional: Heterogeneous pooling
is enabled by default. Under certain circumstances it might be desirable
to disable heterogeneous pooling for a data source. A data source
custom property can be defined to deactivate this pooling support.
The data source custom property is called, enableHeterogeneousPooling.
If enableHeterogeneousPooling is not defined for a data source
or if this property exists for a data source and has the value true,
then heterogeneous pooling is enabled. If enableHeterogeneousPooling is
defined for a data source and has the value false,
then heterogeneous pooling is disabled. To define enableHeterogeneousPooling for
a data source and disable heterogeneous pooling, perform the following
steps:
- Click Resources > JDBC provider > JDBC_provider
- Under additional properties, click Data sources.
- Click the name of the data source.
- Create the enableHeterogeneousPooling custom property.
- Click New.
- Enter enableHeterogeneousPooling for the name field.
- Enter false in the value field to specifies that
you want to disable heterogeneous pooling.
- Click Apply then Save.