Two types of access to data in distributed relational database systems are currently available. They are remote unit of work, which is also known as DRDA1, and distributed unit of work, which is also known as DRDA2.
Remote unit of work (RUOW) allows a user or an application to read or update data at one remote location per unit of work. With remote unit of work, you can have many SQL statements within a unit of work. You can access one database management system with each SQL statement, and you can access one database management system within a unit of work.
Consider a banking example. Using remote unit of work, you can transfer funds from a savings account table to a checking account table, if both tables are at the same remote location. Figure 117 shows how the application first requests an update to the savings account table (1) and then requests an update to the checking account table (2).
Figure 117. Remote unit of work
If both requests are processed successfully, the application can direct the database management system to commit both updates (3). If either request is not processed successfully, the application can issue a ROLLBACK, leaving both tables as they were before the transaction began. This ensures that requests are neither lost nor duplicated.
Distributed unit of work lets a user or application program read or update data at multiple locations within a single unit of work. With distributed unit of work, you can:
Using the banking example (see Figure 118), imagine that the savings account table and the checking account table are on two different computer systems. Distributed unit of work processing permits an application to debit the savings account (1), credit the checking account (2), and either commit or roll back the operations in both computer systems (3), treating all of the changes as a single transaction, or unit of work.
Figure 118. Distributed unit of work
Commit and rollback are coordinated at all locations so that if a failure occurs anywhere in the system, data integrity is preserved. If there was a failure in the middle of the banking transaction just described, and commit or rollback was not coordinated, the savings account could be debited money and the checking account might not be credited the money. This costly error is avoided by the coordination of commit and rollback, or two-phase commit processing. For more information on two-phase commit processing, see Two-Phase Commit Processing.
Table 30 summarizes the level of DRDA support
available for the DB2 Server for VSE application server (AS) and application
requester (AR):
Table 30. DRDA Support in DB2 Server for VSE
|
| VM or VSE AS | VM AR | VSE Batch AR | VSE Online AR |
|---|---|---|---|---|
| RUOW over SNA | yes | yes | no | yes |
| RUOW over TCP/IP | yes | yes | yes | yes |
| DUOW over SNA | yes | no | no | no |
| DUOW over TCP/IP | no | no | no | no |