Page 1 of 3   next page »

Most WebSphere Application Server (WAS) for z/OS customers use DB2 for z/OS as the backend or data store. DB2 for z/OS is a high-performance DBMS, with a strong reputation for handling high-volume data access transactions. Picking the right WAS for z/OS and DB2 Subsystem connectivity architecture can greatly improve the system's performance, availability, scalability, security, and transactional capability.

On the other hand, application developers are always confused by some of the WAS for z/OS DB2 application development concepts such as local transaction, JDBC connection sharing, locking, and isolation-level control. It's necessary to clarify these concepts.

This article will discuss the WAS for z/OS and DB2 Subsystem connectivity architectures and clear up the most confusing WAS for z/OS DB2 application development concepts. If not specifically stated, I'm speaking here of WAS for z/OS V5 (or later) and DB2 for z/OS V7 (or later).

To make the article self-contain, I'll start with some zSeries terminologies even though most of them have appeared in my previous articles. If you're familiar with them, you can jump directly to the JDBC Providers and Drivers on z/OS section.

z/OS Concepts and Terminology
zSeries hardware allows the allocation of resources to multiple logical partitions (LPARs) in a single zSeries machine, with each partition supporting a single z/OS image.

A SysPlex is a collection of LPARs joined together to form a single logical entity or view to an external observer.

A Coupling Facility (CF) is a zSeries machine with microcode that allows high-speed communication between LPARs in a SysPlex as well as a common repository for sharing data by subsystems like DB2 that are in different LAPRs in the SysPlex.

Resource Recovery Service (RRS) is a z/OS component that can perform transaction management for multiple subsystems such as CICS, DB2, WebSphere, and WMQ on the same LPAR.

An application program can use the Resource Recovery Services Attachment Facility (RRSAF) to connect to and use DB2 to process SQL statements, commands, or IFI calls.

Workload Manager (zWLM) uses installation-defined policies and service-level commitments to govern the performance of a workload in the system.

Dynamic Virtual IP Address (DVIPA) is a common external IP address for an application residing or executing on different LPARs in the SysPlex.

Sysplex Distributor (SD) is a z/OS component (part of the TCP/IP stack) that consults zWLM to distribute inbound DVIPA requests to the most suitable LPAR in the SysPlex.

Automatic Restart Management (ARM) is a z/OS component that will try to restart a job or task after a failure.

Data sharing lets multiple DB2 subsystems have concurrent full read and write access to databases on shared direct access storage devices (DASDs).

Distributed Relational Database Architecture (DRDA) is the DB2 database communication protocol.

JDBC Providers and Drivers on z/OS
JDBC is an Application Programming Interface (API) that the Java programming language uses to access different forms of tabular data, as well as some hierarchical systems. Applications developed for WAS for z/OS use JDBC to access data in DB2 Subsystem.

WAS for z/OS provides a Relational Resource Adapter (RRA) implementation. The RRA uses a JDBC driver to access data through JDBC calls to the database. The connection management is based on a JCA connection management architecture. It provides connection pooling, transaction, and security support. WAS for z/OS V5.x supports JCA 1.0, whereas WAS for z/OS V6.0.1 supports both JCA 1.0 and JCA 1.5. In WAS for z/OS a JDBC provider defines a set of JDBC drivers that relates to a particular database type; a Data Source is defined "under" the JDBC provider definition; it contains specific information about the database to which it connects. Applications are mapped to Data Sources.

Three DB2 JDBC providers exist in WAS for z/OS V5.X:

• DB2 Universal JDBC Driver Provider
• DB2 Universal JDBC Driver Provider (XA)
• DB2 for z/OS Local JDBC Driver Provider (RRS)

Table 1 lists the providers and what they offer. JDBC providers can be "scoped" in WAS for z/OS. Three levels of scopes can be set for a JDBC provider: Cell, Node, and Server. Scoping at the Node level is the common approach, though there are reasons to scope lower still. Currently the two DB2 JDBC providers in WAS for z/OS can't coexist because they have same classes with the same names but different implementations, so their scopes mustn't overlap at all. The only two possibilities are:

• One scoped to "Node A" and other scoped to "Node B"
• One scoped to "Server A" and other scoped to "Server B" in same node

The DB2 Universal JDBC Driver supports JDBC 3.0 with both Type 2 driver and Type 4 driver implementations. The Type 4 driver implementation that connects to the DB2 Subsystem uses DRDA over TCP/IP, whereas the Type 2 driver implementation connects to the DB2 Subsystem through RRSAF (it requires DLLs that are included with the DB2 for z/OS V8 and APAR PQ80841 distribution for the driver). So the Type 2 driver implementation's performance is equivalent to that of the "Legacy" Local JDBC Driver.

Considering that the two DB2 JDBC providers can't coexist there's no point in using the "Legacy" Local JDBC Driver if the DB2 Universal JDBC Driver is available in the installation. The migration from the "Legacy" Local JDBC Driver Provider to the Universal JDBC Driver Provider is transparent to application developers.

Then which Type of driver implementation of the DB2 Universal JDBC Driver Provider should you use to connect to the DB2 Subsystem? The answer is, "it depends." Let's take a look at the connectivity options.

WAS for z/OS DB2 Connectivity Options
Note: The Type 2 driver and connection mentioned in this section all refer to the Type 2 driver implementation in the DB2 Universal JDBC Driver Provider. The general recommendation is to use the DB2 Universal JDBC Driver Type 2 implementation for local DB2 connections and Type 4 implementation for remote DB2 connections. "Local" means that the DB2 Subsystem locates in the same LPAR as WAS for z/OS. Whereas the "remote" refers to the DB2 Subsystem located on a different LPAR from the WAS for z/OS.

Page 1 of 3   next page »