DRDA Functions

 <  Day Day Up  >  

Three functions are utilized by DRDA to provide distributed relational data access:

  • Application Requester (AR)

  • Application Server (AS)

  • Database Server (DS)

These three functions inter- operate with one another to enable distributed access (see Figure 41.1).

Figure 41.1. The three DRDA functions.

graphics/41fig01.gif


Let's further examine these three functions.

Application Requester

The DRDA application requester (AR) function enables SQL and program preparation requests to be requested by application programs. The AR accepts SQL requests from an application and sends them to the appropriate application server (or servers) for subsequent processing. Using this function, application programs can access remote data.

In theory, if all of the data that you are interested in is physically located somewhere else (for example, remote), there may be no need for a local RDBMS, and DRDA does not require the requester to run on a system with a local RDBMS.

For the DB2 Family, the DRDA AR function is implemented using DB2 Connect.

Application Server

The DRDA application server (AS) function receives requests from application requesters and processes them. These requests can be either SQL statements or program-preparation requests. The AS acts upon the portions that can be processed and forwards the remainder to DRDA database servers for subsequent processing. This is necessary if the local RDBMS cannot process the request.

The AR is connected to the AS using a communication protocol called the Application Support Protocol. The Application Support Protocol is responsible for providing the appropriate level of data conversion. This is only necessary when different data representations are involved in the request. An example of this is the conversion of ASCII characters to EBCDIC (or vice versa).

Database Server

The DRDA database server (DS) function receives requests from application servers or other database servers. These requests can be either SQL statements or program preparation requests. Like the application server, the database server will process what it can and forward the remainder on to another database server.

It is important to note that a database server request may be for a component of an SQL statement. This would occur when data is distributed across two subsystems and a join is requested. The join statement is requesting data from tables at two different locations. As such, one portion must be processed at one location; the other portion at a different location.

Because the database servers involved in a distributed request need not be the same, the Database Support Protocol is used. It exists for the following reasons:

  • To connect an application server to a database server

  • To connect two database servers

Like the Application Support Protocol, the Database Support Protocol is used to ensure compatibility of requests between different database servers.

What Is Returned

When a request is completely processed, the application server must inform the requesting process, the application requester. How is this accomplished?

The AS passes a return code and a result set (if one was produced) back to the AR. The return code is the SQLSTATE (or SQLCODE ). A result set is not generated under the following circumstances:

  • INSERT

  • UPDATE

  • DELETE

  • SELECT , when no rows qualify

  • DCL and DDL requests

This protocol is used unless a cursor is employed. When rows are fetched from a read-only cursor limited block protocol can be used. Limited block protocol passes multiple rows across the network at a time, even though one fetch can process only a single row at a time. Limited block protocol enhances overall performance by minimizing network traffic. If the cursor is not read-only (that is, rows can be updated) limited block protocol is not employed.

 <  Day Day Up  >  


DB2 Developers Guide
DB2 Developers Guide (5th Edition)
ISBN: 0672326132
EAN: 2147483647
Year: 2004
Pages: 388

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net