+

Search Tips   |   Advanced Search

Administer data access applications

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.


Tasks

  1. If the 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 we 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 ), configure a resource adapter and connection factories. The topic, Accessing data using Java EE Connector Architecture connectors, provides information on setting up these objects.

    When we specify the 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.

  2. 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, we can alter the container-managed authentication alias using the administrative console. Click Applications > Websphere enterprise applications > application_name, and select the link to the appropriate mapping page. For example, to alter the alias of an EJB module resource, we 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.

  3. If the application contains a client module that requires data access, see the topic, Configuring data access for application clients. In this single configuration process, we can define authentication data for either component-managed or container-managed signon.

  4. Specify connection pool settings.
  5. 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 our test connection results.

  6. 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.

  7. Gather connection pool statistics by activating the JDBC connection pool counters or the J2C connection pool counters. Alternatively, we can use Performance Monitoring Infrastructure (PMI) method calls to gather connection statistics; see the topic, Connection and connection pool statistics.

  8. Tune the resources to manage connection volume. See the topic, Data access tuning parameters.

  9. (iSeries) Tune the database to accommodate the connection volume. If we use DB2 UDB for iSeries, see the topic, DB2 Universal Database performance tips, as a starting point reference.

(ZOS)

If our z/OS application connects to a z/OS version of DB2 that serves multiple platform versions of WAS, the z/OS application might incur an EC3 dump during run time. To resolve the problem, set the CMTSTAT parameter to INACTIVE when we plan to run distributed workloads.

For DB2 Version 7.0 on a z/OS system, the default value for CMTSTAT is ACTIVE. For DB2 v9.0 on a z/OS system, the default setting is set to INACTIVE. 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 we set CMTSTAT=INACTIVE, we might need to adjust the CONDBAT and AXDBAT parameters as well. Try the following combination of values to maximize the performance of DB2 and minimize suspended connection requests:


Subtopics


Related:

  • Relational resource adapters and JCA
  • JDBC providers
  • Data sources
  • Java EE connector security
  • Connection pooling
  • Accessing data using Java EE Connector Architecture connectors
  • Install a resource adapter archive
  • Configure data access for application clients using the assembly tool and ACRCT
  • Perform platform-specific tasks for JDBC access
  • (iSeries) Configure data access security
  • Passing client information to a database
  • Configure JDBC providers to use pureQuery to access DB2
  • Enable trace at server startup
  • Application scoped resources
  • Data source minimum required settings, by vendor
  • Database performance tuning
  • DB2 tuning parameters
  • (ZOS) DB2 tuning tips for z/OS
  • (iSeries) DB2 Universal Database performance tips
  • Data access tuning parameters
  • J2C connection pool counters