Using two different datasources that interface with two different DB2 subsystems, with a single J2EE server instance
 Technote (FAQ)
 
Problem
You use two different datasources, using two different DB2® subsystems, with a single J2EE server instance . One of these datasources (session clustering) points to the same DB2 subsystem in which WebSphere® Application Server was installed. The second datasource (application data) points to a second DB2 location that is not the DB2 in which WebSphere Application Server was installed.
 
 
Solution
When you setup a WebSphere Application Server for z/OS system, you specify the following values in the current.env file (through environment variables at the sysplex level or a lower level):
  1. SYS_DB2_SUB_SYSTEM_NAME=DB2_subsystem_name_in_which_ WAS_systems_management_tables_reside

  2. DB2SQLJPROPERTIES=location_of_the_db2sqljjdbc.properties_file

The first specification indicates the DB2 subsystem that the WebSphere Application Server uses to retrieve runtime configuration information. All of these accesses are done using static SQL that is baked into the C code that is responsible for getting the server up and running.

In a WebSphere Application Server configuration, you can define one or more DB2 Datasources as J2EE resources that can have different location names in them. For example, you can have a datasource for the location names WASDS1 and WASDS2. These are actually two different DB2 datasharing groups on the same PLEX, which have members on one or more machines. In this case, there is an instance of WASDS1 active on the system where the WebSphere Application Server is running and there might or might not be an active instance of WASDS2 on this system. However, WASDS1 is the DB2 subsystem with which the JDBC driver communicates.

How does the JDBC® driver find the DB2 subsystem it must use?

The DB2 V7 JDBC driver is a type 2 driver, there is native code that interacts with DB2, like calling DB2 from a batch job, CICS or IMS. This DB2 driver is going to communicate with a DB2 subsystem that is on this z/OS image.

If there are two DB2 subystems active on the MVS image which one does the JDBC Driver use?

Normally, the name of the DB2 subsystem is determined by the contents of the db2sqljjdbc.properties file in the second specification. This file contains the following variable:

DB2SQLJSSID=name_of_the_DB2_subsystem_to_be used_by_the_JDBC_driver

If DB2SQLJSSID is not specified in this file, the JDBC driver uses the DB2 subsystem name specified in the DSNHDECP module in the DSN710.SDSNEXIT PDS to find the correct DB2 subsystem. The DB2 subsystem specified in the properties file or the DSNHDEP module must either:
  1. Be the location name specified in the datasource definition that you specified in the WAS configuration

    or

  2. There must be definition for the location name in the SYSIBM.SYSLOCATIONS (and some other miscellaneous definitions)
You can have any application reference table in either DB2 data sharing environment by using the correct data source. However, the JDBC driver talks to only one DB2 subsystem. If the location name is associated with another DB2 subsystem (or data sharing group) and is known to the DB2 subsystem to which the JDBC driver uses, you must flow a request through the DB2 subsystem that the JDBC driver uses to get to the destination subsystem through DDF. This is true if the subsystem is on the same z/OS image or on a different z/OS image.

It is not possible to have the WebSphere Application Server running on a z/OS image with two DB2 subsystems and get a direct connection to each of the DB2 subsytems so that the JDBC driver talks to the appropriate DB2 subystem. Even if you define two DB2 datasources, this is not possible. There is only one db2sqjljdbc.properties file and one DSNHDECP module available in the address space.

WebSphere Application Server for z/OS V4 has the WebSphere Application Server configuration data in one DB2 subystem; all the JDBC accesses from the runtime use a different DB2 subsystem. That is what the two specifications at the top of this technote allow you to define.

If you want to place HTTP session data in the DB2 subsystem in which the WebSphere Application Server tables live, you must set this up as a DDF flow from the DB2 subsystem that the JDBC communicates with, to the DB2 subsystem that is connected to your WebSphere Application Server for z/OS system.
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server for z/OS > DB Connections/Connection Pooling
Operating system(s): OS/390
Software version: 4.0.1
Software edition:
Reference #: 1108098
IBM Group: Software Group
Modified date: May 25, 2004