Putting It All Together

Consider a scenario where three remote processing locations are set up, each with a RDBMS: Pittsburgh, Chicago, and Jacksonville. Let's examine how each of the four DRDA options could access distributed data from these locations (see Figure 41.3).

Figure 41.3. DRDA remote request.

Consider a situation whereby we need to access specific columns from tables at each remote location. Furthermore, assume that the requests are emanating from Chicago.

Refer to Figure 41.3 for a depiction of remote request distributed access. In this scenario, we can access only a single RDBMS from a single location in a single unit of work. The request for the Chicago table is a local request; the Pittsburgh and Jacksonville requests are remote. Each request is within a single unit of work (indicated by the COMMIT ).

Remote unit of work functionality is depicted in Figure 41.4. Contrast this diagram with remote request. Instead of a single statement per unit of work, multiple statements can be issued (see the Pittsburgh example).

Figure 41.4. DRDA remote unit of work.

Distributed unit of work enables multiple RDBMSs per unit of work. This is shown in Figure 41.5.

Figure 41.5. DRDA distributed unit of work.

All four tables from all three locations can be accessed within one unit of work using DRDA DUW functionality.

Finally, Figure 41.6 depicts distributed request. Using distributed request, multiple RDBMSs from multiple locations can be accessed using a single SQL statement. In this scenario, the application requester sends a request to the Chicago application server, which in turn sends the request to the Chicago database server. It processes what it can and passes it to one of the other database servers (in, say, Pittsburgh), and so on.

Figure 41.6. DRDA distributed request.