Page 2 of 3   « previous page   next page »

Option 1
As shown in Figure 1, a Type2 connection to a local DB2 Subsystem offers the best performance because of the connection through RRSAF (memory to memory communication). The scalability and availability are somehow limited to the DB2Subsystem on a single LPAR. Since the Type 2 connection supports thread-level security, it has some special security advantages. RRS is exploited to handle two-phase commits in this architecture. Theoretically nothing prevents you from using a Type 4 driver for the local DB2 subsystem connection, but the performance will be 50% worse and thread-level security support is no longer available. So it's not recommended.

Option 2
A Type 4 connection is the better choice in connecting to a remote DB2 Subsystem. It performs better than a Type 2 driver connecting to a local DB2 Subsystem and subsequently to the remote target DB2 Subsystem. The connectivity architecture is shown in Figure 2. Compared to Option 1, it has worse performance and worse availability (more single points of failure) but better scalability (subsystems on different LPARs can scale independently). Type 4 XA connection can be established to handle two-phase commit. Unfortunately, thread-level security isn't supported in this architecture option.

Option 3
Of course, you can combine Option1 and Option2 - connect to the local DB2 Subsystem through a Type 2 connection and the remote DB2 Subsystem through a Type 4 connection. It applies when your application has to access both the local and remote DB2 Subsystems at the same time. To do so, you should define different Data Sources in WAS for z/OS.

From a performance and security perspective, it's recommended that WAS for z/OS co-locates in the same LPAR with the DB2 Subsystem so that Type 2 connections can be used by the applications. As previously stated, a Type 2 connection greatly out-performs a Type 4 connection. Using thread-level security you can propagate a customer id to DB2 rather than a common proxy id. Applications that need tracing and auditing at the individual customer level can exploit this nice feature in the Type 2 driver implementation.

To use thread-level security you have to understand the thread identity and thread security concepts exclusive to WAS for z/OS available for JCA connectors. Thread identity support is used to flow the current thread identity to the backend EIS (Enterprise Information System). Once the user is authenticated, his id flows to any work he does in the z/OS system, cutting an SMF(System Management Facility) audit trail records as it goes. Thread security can be used to "push down" the current thread identity onto the OS thread. The Type 2 driver implementation captures the id from the OS thread.

Certain conditions should be met to use thread-level security. The WAS for z/OS user repository must be a local OS registry. The JCA connection must be container-managed. And the Connection Manager RunAs Identity Enabe has to be enabled as shown in Figure 3.

So far we've discussed WAS for z/OS and DB2 for z/OS in the context of a single LPAR. To improve overall scalability and availability the WAS for z/OS Network Deployment (ND) and DB2 data-sharing group in a SysPlex environment has to be exploited.

Option 4
Look at Figure 4. It depicts a Type 2 local connection architecture in a SysPlex environment in which each WAS for z/OS connects to the DB2 Subsystem in the same LPAR. Besides the performance and security advantages, the cross-LPAR WAS cluster combined with the DB2 data-sharing group has better scalability and availability than that in a single LPAR.

There's a major problem with the architecture when the WAS server is up running but the DB2 Subsystem isn't available. User requests are distributed to WAS servers by the SD based on each WAS server's workload and status (provided by the zWLM). Because the WAS server is running fine, more and more workloads are sent to the WAS server, creating a storm drain. The problem can be solved to a certain extent by using ARM to restart the DB2 Subsystem. When the DB2 Subsystem is recycled the JDBC Type 2 driver can reconnect to the same DB2 Subsystem and purge the dead connections.

There are two facts about this architecture worth noting: the two-phase commit is handled through RRS and the DB2 connections are attached to a specific member of the DB2 data-sharing group instead of to the group itself.

Option 5
If the Type 2 connections in Option 4 are replaced by Type 4 connections and use SD, the connections are directed to the DB2 data-sharing group. So all the single points of failure are removed. The new architecture is depicted in Figure 5. It provides the highest level of availability and DB2 Subsystem location transparency. Taking the Type 4 driver's XA support into consideration, it seems like an attractive solution for DB2 connectivity. Unfortunately the architecture is 't recommended because global transactions can be deadlocked.

When multiple JDBC connections participate in a global transaction, all branches of the transaction share locks. Uncommitted changes made by one branch are visible to every branch. Unfortunately SysPlex doesn't support global transactions; all JDBC connections must process against a single subsystem (a single member of the data-sharing group) to share locks. Since Type 4 connections are directed to the DB2 data-sharing group they can be routed to different DB2 Subsystems by the SD. Whenever that happens, you're exposed to deadlocks. To avoid them, you have to serially reuse the same connection just like using a local connection. But you lose the level of availability added by the SD.

However the performance of a local DB2 Subsystem suffers in a Type 4 connection versus a Type 2 connection. Why use a Type 4 connection if you're forced to use local connection?

Normally Option 4 would be the recommended connectivity architecture in a production environment. But you should still evaluate the application needs and infrastructure constraints before making a decision. You may be wonder how to handle two-phase commit with XA resources if you choose Option 4. Actually WAS for z/OS provides two-phase commit support for transactions that access both XA resources and RRS resources in the same transaction.

WAS for z/OS Local Transaction
Local transaction is the first concept that has to be clarified. To understand local transaction, let's make a detour to global transaction first. A global transaction is a logical unit of work (LUW) that spans multiple resource managers such as DB2 and MQ. The J2EE specification defines a global transaction's behavior. As you can guess, a local transaction refers to a LUW that doesn't span multiple resource managers.

A resource manger local transaction (RMLT) is a resource manager's view of a local transaction; that is, it represents a unit of recovery on a single connection that's managed by the resource manager.

An LTC is a bounded unit-of-work scope in which zero, one, or more resource manager local transactions (RMLTs) can be accessed. The LTC defines the boundary at which all RMLTs must be complete; any incomplete RMLTs are resolved according to policy by the container. An LTC is local to a bean instance. The LTC defines the application server's behavior in an unspecified transaction context. The unspecified transaction context is defined in the EJB 2.0 (or later) specification. An example of an unspecified transaction context is the EJB transaction attribute Not supported.

If you want to access several non-XA resources in a method and manage them independently, you should use LTC. As shown in Figure 6, Local Transactions - Resolver should be set to Application and Local Transactions - Unresolver action should be set to Rollback in the component's deployment descriptor. In the Container transaction deployment descriptor, the Transaction should be set to Not supported.

Page 2 of 3   « previous page   next page »