These administrative tasks consist primarily of configuring
the objects, or resources, through which applications connect with
a backend, and tuning those resources to handle the volume of connection
requests.
Procedure
- If your application contains web modules or EJB modules
that require access to a backend, configure resources according to
your type of enterprise information system (EIS):
- For a relational database, follow the steps outlined in the
topic, Configuring a JDBC provider and data source. If you are using
a DB2® database, the topic, Configuring an application
to use pureQuery is another option. IBM Optim PureQuery Runtime provides
an alternative to JDBC as a way to access the DB2 database.
- For a non-relational database, or another type of EIS such
as the Customer Information Control System (CICS®),
you must configure a resource adapter and connection factories. The
topic, Accessing data using Java EE Connector Architecture connectors,
provides information on setting up these objects.
Avoid trouble: When you specify the Java Naming
and Directory Interface (JNDI) name for resources, adhere to the following
requirements:
- Do not assign duplicate JNDI names across different resource types
(such as data sources versus J2C connection factories or JMS connection
factories).
- Do not assign duplicate JNDI names for multiple resources of the
same type in the same scope.
gotcha
- Configure an authentication alias for the new web module
resource or EJB module resource only if the application code, rather
than WebSphere® Application Server, authenticates
connections with the backend. This security configuration
is called component-managed authorization, and is indicated in the
application deployment descriptor as res-auth = Application.
Container-managed
authorization, which is designated as res-auth = Container,
indicates that Application Server performs signon for backend connections.
The container-managed authentication alias must be specified on the
application resource reference. This task can be done during application
assembly or deployment, along with mapping the resource reference
to a data source or connection factory resource. After application
deployment, however, you can alter the container-managed authentication
alias using the administrative console. Click , and select the link to the appropriate mapping page.
For example, if you want to alter the alias of an EJB module resource,
you might click Map data sources for all 2.x CMP beans.
For a web module resource, click Resource References.
Read
the J2EE connector security topic for detailed reference on resource
authentication.
- If your application contains a client module that requires
data access, see the topic, Configuring data access for application
clients. In this single configuration process, you can
define authentication data for either component-managed or container-managed
signon.
- Specify connection pool settings.
- Test a connection to the new data source. See
the article, Test connection service, for information on the available
methods for testing connections. This article also addresses important
data source settings that can affect the accuracy of your test connection
results.
- Set the JDBC trace service. The JDBC trace log
information augments the JVM log data for data source failures.
To
activate the trace using the administrative console, read the topic,
Enabling trace at server startup.. Specify WAS.database as
the trace group and select com.ibm.ws.db2.logwriter as the
trace string.
- Gather connection pool statistics by activating the JDBC
connection pool counters or the J2C connection pool counters. Alternatively,
you can use Performance Monitoring Infrastructure (PMI) method calls
to gather connection statistics; see the topic, Connection and connection
pool statistics.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Tune the resources to manage connection
volume. See the topic, Data access tuning parameters.
Tune your database to accommodate the
connection volume. If you use DB2 UDB
for iSeries®, see the topic, DB2 Universal Database
performance tips, as a starting point reference.
Results
If your z/OS® application
connects to a z/OS version of DB2 that
serves multiple platform versions of
WebSphere Application Server, the z/OS application
might incur an EC3 dump during run time. To resolve the problem, set
the CMTSTAT parameter to INACTIVE when you plan to run distributed
workloads.
Avoid trouble: For DB2 Version
7.0 on a z/OS system, the default value for CMTSTAT is
ACTIVE. For DB2
Version 8.5 on
a z/OS system, the default setting is set to INACTIVE.
gotcha
Distributed
workloads are generally large. The CMTSTAT=INACTIVE setting triggers DB2 to
free up resources to counteract the drain that can be caused by large
workloads. DB2 will deactivate threads after the threads
successfully commit or roll back database tasks and release cursors.
If
you set CMTSTAT=INACTIVE, you might need to adjust the CONDBAT and
MAXDBAT parameters as well. Try the following combination of values
to maximize the performance of DB2 and
minimize suspended connection requests:
- Set MAXDBAT to a low number, like 100, which DB2 can
support as active threads. MAXDBAT indicates the maximum number of
threads that can remain active at the same time and continue running
tasks in DB2.
- Set CONDBAT to a high number, like 5000. CONDBAT indicates the
maximum number of connection request threads that your DB2 server
can receive. When you set CMTSTAT to INACTIVE, DB2 will
deactivate many threads after fulfilling the initial connection requests.
When the number of threads that require further processing reaches
the MAXDBAT setting, DB2 can queue other threads until
it can handle them.