Today's Top SOA Links
IBM WebSphere Application Server - WAS for z/OS and DB2
Clearing up some of the conceptual confusion
By: Linfeng Yu
Oct. 12, 2005 05:15 PM
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
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
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:
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:
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
Reader Feedback: Page 1 of 1
Web 2.0 Latest News
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week