As an AS/400 programmer for a growing, dynamic company, you're always facing new challenges. A couple of months ago, you implemented referential integrity and triggers in the Order Entry System to address data integrity needs and to provide more flexibility in managing accounts receivable and special sales promotions.

This month, the challenges continue as your company grows and opens up new markets. It's going to add remote warehouses in Chicago and Dallas to supplement the home office warehouse in New York and establish a remote sales force to service the new markets. Each of the two remote locations will need a small AS/400 to provide support for the warehouse staff and sales force. The inventory application will coordinate inventory control with the home office and the database on each of the remote systems, as illustrated in 1.

This month, the challenges continue as your company grows and opens up new markets. It's going to add remote warehouses in Chicago and Dallas to supplement the home office warehouse in New York and establish a remote sales force to service the new markets. Each of the two remote locations will need a small AS/400 to provide support for the warehouse staff and sales force. The inventory application will coordinate inventory control with the home office and the database on each of the remote systems, as illustrated in Figure 1.

These two additional AS/400s have you unexpectedly plunging headfirst into the world of distributed database. In the past, modifying or developing applications to work with a database that was spread across multiple systems represented a significant amount of complex, unique design and coding effort- especially to ensure a reasonable level of application performance and database integrity across systems.

Distributed Relational Database Architecture Level 2 (DRDA Level 2) offers an alternative to help minimize the performance impact of operating in the distributed database environment; two phase commitment control (two phase commit) can be used to ensure data integrity in the same environment. These are two of the new features of DB2/400, so every AS/400 programmer needs to know how to use them effectively. This article shows you how. It begins by defining DRDA Level 2 and two phase commit at a conceptual level. After that, you'll learn how to use these features of DB2/400 to solve the problems presented by moving into distributed database. Along the way, you'll become familiar with the key concepts you need to understand to effectively use these new database functions.

DRDA Level 2

DRDA Level 2 supports application-directed distributed unit of work (DUW). A unit of work is a single application program transaction that can contain one or more database transactions that are logically related. DRDA Level 2 is called application directed because the application program uses SQL statements to direct or control which database it is working with.

DUW is only available through the SQL interface. It lets DB2/400 connect to, access, and update multiple relational databases within the same unit of work in an application program. When the unit of work is completed, two phase commit can be used to ensure that all databases have been successfully updated.

Unlike DRDA Level 1 (the initial DRDA offering), DRDA Level 2 needs to physically establish a communications session with a remote system only once per application. Once established, the communications session can be logically disconnected and reconnected as required by the application, significantly reducing the overhead required and improving application performance compared to DRDA Level 1. This makes DRDA Level 2 a powerful tool to minimize communication overhead in a distributed database or client/server environment.

Two Phase Commitment Control

Two phase commit lets DB2/400 apply a single application transaction-which may be composed of several database updates-to two or more databases spread across multiple systems, and ensures that all the database updates are completed before committing the changes. If the update to any database is not completed, updates are rolled back from all the databases participating in the transaction. This makes two phase commit a powerful tool to ensure database integrity across multiple systems.

The Challenge: Distributed Inventory Database

With DRDA Level 2 and two phase commit, we can begin to see how to solve the problems of implementing a distributed inventory database. The problems are connecting to, and communicating with, the three AS/400s in the network, and maintaining the inventory database when it is distributed across these three systems.

When a single inventory transaction affects the database on each of the three systems, a communications session has to be established with each system, and the database on each system has to be updated correctly. Then the integrity of the transaction needs to be ensured across all three systems. If the database is correctly updated on the New York and Dallas systems, but there is a communications failure before the Chicago database can be updated, how can the integrity of the database be ensured? To resolve these problems, IBM has now implemented DRDA level 2 and two phase commit in DB2/400.

DRDA Level 2 and two phase commit are often discussed in the same context and are used together in a large number of application programs. Because of their relationship to each other, they are included in the same discussion in this article. However, they are separate functions that can stand alone and be used independently. Let's begin by discussing DRDA Level 2.

DRDA Level 2 Concepts

As discussed earlier in this article, DRDA Level 2 supports DUW, which allows an application program using SQL to connect to and update multiple relational databases within the same unit of work. DUW allows multiple SQL statements within the unit of work, and each SQL statement can be directed to a different database.

Application Requester and Application Server

In all levels of DRDA, SQL statements in an application program residing on a local system request data from a database residing on a remote system. The local system is called the Application Requester (AR) or source system, since it is the source of the SQL statements. The remote system is called the Application Server (AS) or target system, since it is the target of the SQL request from the AR and will serve the request by returning the data that satisfies it. These terms will be used throughout the rest of this discussion. 2 illustrates the concept.

In all levels of DRDA, SQL statements in an application program residing on a local system request data from a database residing on a remote system. The local system is called the Application Requester (AR) or source system, since it is the source of the SQL statements. The remote system is called the Application Server (AS) or target system, since it is the target of the SQL request from the AR and will serve the request by returning the data that satisfies it. These terms will be used throughout the rest of this discussion. Figure 2 illustrates the concept.

DRDA uses SQL statements that originate from an AR to request information from an AS database. DRDA can be used by application programs that contain embedded SQL statements. It can also be used by interactive SQL, Query Manager/400, Query Management/400, and the application programming interfaces(APIs) that access databases for PCs used as workstations. There is no native support (CL commands) for DRDA in DB2/400.

Unit of Work and Remote Unit of Work

To better understand DUW, let's look at unit of work and DRDA Level 1: Remote Unit of Work (RUW). A unit of work is a single transaction from an application program. This transaction can contain one database update or multiple updates that are logically grouped or related. In a commitment control environment, a unit of work is defined as the database updates that occur between COMMIT statements.

DRDA Level 1 supports RUW, which limits the unit of work to one AS database. This means that the application program can be connected to only one AS database at a time. 3 uses your new AS/400 network to illustrate RUW. Note that the transaction from the application program on the AR has several database updates that apply to the AS databases on the Chicago and Dallas systems. RUW limits each unit of work from the AR to a single AS database at a time, so the application transaction in this case has to be split into two separate units of work.

DRDA Level 1 supports RUW, which limits the unit of work to one AS database. This means that the application program can be connected to only one AS database at a time. Figure 3 uses your new AS/400 network to illustrate RUW. Note that the transaction from the application program on the AR has several database updates that apply to the AS databases on the Chicago and Dallas systems. RUW limits each unit of work from the AR to a single AS database at a time, so the application transaction in this case has to be split into two separate units of work.

When the connection is established for the Dallas system, the Chicago system automatically disconnects and ends its communications session with the application on the AR. Each time a connection is made to an AS database, the previous communications session is ended and is disconnected from the application on the AR. A new session is then established for the next AS database. The system resources required to perform these functions can be significant.

Distributed Unit of Work-Application Directed

Because DUW allows an application program to connect to and update multiple relational databases within the same unit of work, it does not end a communications session with an AS database when a connection is made to a different AS database. After the unit of work is completed, two phase commit can be used to ensure that all the databases have been successfully updated. The example for RUW can be changed to illustrate DUW. (See 4.) The application program on the AR applies the same database transactions to the AS databases on the Chicago and Dallas systems. However, unlike RUW, DUW allows a unit of work from the AR to span multiple AS databases, so the application transaction can now be handled as a single unit of work.

Because DUW allows an application program to connect to and update multiple relational databases within the same unit of work, it does not end a communications session with an AS database when a connection is made to a different AS database. After the unit of work is completed, two phase commit can be used to ensure that all the databases have been successfully updated. The example for RUW can be changed to illustrate DUW. (See Figure 4.) The application program on the AR applies the same database transactions to the AS databases on the Chicago and Dallas systems. However, unlike RUW, DUW allows a unit of work from the AR to span multiple AS databases, so the application transaction can now be handled as a single unit of work.

When the connection is made to the Dallas system, the Chicago system is logically disconnected; the physical connection and communications session still exist but are inactive. Under DUW, any communications sessions established with AS databases during a unit of work remain in effect throughout the unit of work, though they are rendered inactive after serving the requested data. Any connection or session can be reactivated by reconnecting to the AS database associated with it. As a result, DUW uses significantly fewer resources than RUW.

Implementation Considerations

When an application program is designed to implement DRDA, the level of DRDA that will be used is specified in a new parameter-RDBCNNMTH-in the Create SQL Program (CRTSQLxxx) command. This parameter has two options: RDBCNNMTH(*RUW)- remote unit of work; and RDBCNNMTH(*DUW)-distributed unit of work (the default value). SQL/400 uses DUW by default and Query Manager has a new feature in V3R1 called a Query Manager Profile that controls the use of DUW and RUW.

Existing DRDA applications may have to be modified to take advantage of DUW. However, the effort will probably be worthwhile because DUW should offer better performance than RUW. This is because of the decrease in system resources required to establish communications sessions.

Now that we have discussed DRDA Level 2 and understand the benefits it provides in a distributed database environment, the next thing to look at is ensuring the integrity of an application transaction in this same environment.

Commitment Control Concepts

As discussed earlier in this article, two phase commit lets DB2/400 apply a single application transaction-which may be composed of several database updates-to two or more databases on multiple systems. It then ensures that all the updates were successfully completed.

To better understand two phase commit, let's look at how single phase commitment control works in conjunction with RUW. Single-Phase Commit was available on earlier versions of the AS/400 database, and is typically used with RUW transactions.

For the purposes of this explanation, let's use the RUW example in 5. The transaction from the application program on the AR has several database transactions that apply to AS databases on the Chicago and Dallas systems. Because RUW limits a unit of work to a single AS database, the application transaction has to be split into two separate units of work. Note that after the SQL statements have been completed for each unit of work, a COMMIT statement is issued to ensure that the database updates have been applied on each AS database.

For the purposes of this explanation, let's use the RUW example in Figure 5. The transaction from the application program on the AR has several database transactions that apply to AS databases on the Chicago and Dallas systems. Because RUW limits a unit of work to a single AS database, the application transaction has to be split into two separate units of work. Note that after the SQL statements have been completed for each unit of work, a COMMIT statement is issued to ensure that the database updates have been applied on each AS database.

Single phase commit cannot ensure the integrity of the entire application transaction because it is composed of two separate units of work, and only a single unit of work can be ensured. If the second unit of work did not complete successfully and was rolled back, the transaction would be in a partially completed state because the first unit of work would have already been committed. To resolve this situation and return the database to its earlier state, the user would have to use journal receiver entries to explicitly remove the database transactions from the Chicago database. Two phase commit and DUW avoid this problem.

Let's look at two phase commit used in conjunction with DUW and see how it ensures the integrity of the entire application transaction. (See 6.) Since DUW is being used, the unit of work can span the AS databases for both Chicago and Dallas. Under two phase commit, only a single COMMIT statement is needed for the entire transaction. The COMMIT statement is issued when the last database update has been applied and the unit of work is completed.

Let's look at two phase commit used in conjunction with DUW and see how it ensures the integrity of the entire application transaction. (See Figure 6.) Since DUW is being used, the unit of work can span the AS databases for both Chicago and Dallas. Under two phase commit, only a single COMMIT statement is needed for the entire transaction. The COMMIT statement is issued when the last database update has been applied and the unit of work is completed.

Two phase commit ensures the completion of the database updates in all the affected AS databases since the entire application transaction is treated as a single unit of work. If a system or resource failure prevents any of the database updates in the unit of work from completing, the updates that have been applied will be rolled back from the affected AS databases automatically.

In the first phase of two phase commit, the AR prepares to perform the commit by asking the AS databases if they have completed their updates and are ready to commit them. If all the affected AS databases respond that they are ready, the second phase occurs and the actual commitment of the database updates takes place on each AS database, as 7 illustrates. If any AS database sends a negative response, the unit of work is rolled back.

In the first phase of two phase commit, the AR prepares to perform the commit by asking the AS databases if they have completed their updates and are ready to commit them. If all the affected AS databases respond that they are ready, the second phase occurs and the actual commitment of the database updates takes place on each AS database, as Figure 7 illustrates. If any AS database sends a negative response, the unit of work is rolled back.

Implementation Considerations

When DB2/400 runs a transaction under two phase commit, it uses journal entries to track the unit of work. Within any unit of work, resynchronization will be required when a resource or system failure occurs during a COMMIT or ROLLBACK operation. When this happens, all database updates in the unit of work will be rolled back if processing has not progressed far enough to make the decision to commit.

Two phase commit is supported by all Distributed Data Management (DDM), DRDA, and CICS/400 applications as well as Intersystem Communication Function (ICF) and Common Programming Interface (CPI-C) communications files. Current applications may have to be modified to take advantage of the facility. Applications need to have one or more commits removed to take advantage of this facility.

Now that you have an understanding of DRDA Level 2 and two phase commit, let's see how they would be used to solve the problems of connecting to and communicating with the three AS/400s in the network and maintaining the inventory database when it is distributed across these three systems.

Advanced Database Functions

8 illustrates how DRDA Level 2 and two phase commit would be implemented within an application program that accesses and updates the inventory databases on multiple systems. Used as illustrated, it solves the problems of connecting to each system in the distributed network and ensures the integrity of the inventory database transactions across the systems.

Figure 8 illustrates how DRDA Level 2 and two phase commit would be implemented within an application program that accesses and updates the inventory databases on multiple systems. Used as illustrated, it solves the problems of connecting to each system in the distributed network and ensures the integrity of the inventory database transactions across the systems.

DUW uses SQL to allow the application on the New York home office system to connect to and update the distributed inventory databases on the New York, Chicago, and Dallas systems within the same unit of work. Under DUW, all communications sessions established remain in effect during the unit of work, though they are rendered inactive after serving the requested data. Any session can be reactivated by reconnecting to the AS database in question. As a result, DRDA Level 2 DUW provides better application performance and uses significantly fewer resources than its predecessor DRDA Level 1 RUW.

Two phase commit lets DB2/400 apply a single application transaction running on the New York home office system (which can be composed of several database updates) to the distributed inventory database on the New York, Chicago, and Dallas systems, and ensures that all the updates were successfully completed. If an update to any database is not completed successfully, updates are automatically rolled back from all the other databases participating in the transaction.

Thus, DRDA Level 2 DUW and two phase commit-two of the new, advanced functions of DB2/400-can be used to design and implement an efficient application solution in the distributed database environment.

Skip Marchesani is the author of DB2/400: The New AS/400 Database. He can be reached through Midrange Computing.

DRDA Lvl 2 & Two Phase Commitment Cntrl in DB2/400

Figure 1 Multiple Systems Database

 UNABLE TO REPRODUCE GRAPHICS 
 
 DRDA Lvl 2 & Two Phase Commitment Cntrl in DB2/400
 
 Figure 1 Demonstrating the Inventory Application
 
 UNABLE TO REPRODUCE GRAPHICS 
 
 DRDA Lvl 2 & Two Phase Commitment Cntrl in DB2/400
 
 Figure 2 Application Requester and Application Server
 
 UNABLE TO REPRODUCE GRAPHICS 
 
 DRDA Lvl 2 & Two Phase Commitment Cntrl in DB2/400
 
 Figure 3 Remote Unit of Work
 
 UNABLE TO REPRODUCE GRAPHICS 
 
 DRDA Lvl 2 & Two Phase Commitment Cntrl in DB2/400
 
 Figure 4 Distributed Unit of Work
 
 UNABLE TO REPRODUCE GRAPHICS 
 
 DRDA Lvl 2 & Two Phase Commitment Cntrl in DB2/400
 
 Figure 5 Single Phase Commit and Remote Unit of Work
 
 UNABLE TO REPRODUCE GRAPHICS 
 
 DRDA Lvl 2 & Two Phase Commitment Cntrl in DB2/400
 
 Figure 6 DRDA Level 2 and Two Phase Commit
 
 UNABLE TO REPRODUCE GRAPHICS 
 
 DRDA Lvl 2 & Two Phase Commitment Cntrl in DB2/400
 
 Figure 7 The Two Phases of Two Phase Commit
 
 UNABLE TO REPRODUCE GRAPHICS