Remote unit of work
A remote unit of work lets a user or application program read or update data at one location per unit of work. It supports access to one database within a unit of work. While an application program can update several remote databases, it can only access one database within a unit of work.
Remote unit of work has the following characteristics:
- Multiple requests (SQL statements) per unit of work are supported.
- Multiple cursors per unit of work are supported.
- Each unit of work can update only one database.
- The application program either commits or rolls back the unit of work. In certain error circumstances, the database server or DB2 Connect™ might roll back the unit of work.
For example, Figure 1 shows a database client running a funds transfer application that accesses a database containing checking and savings account tables, as well as a transaction fee schedule. The application must:
- Accept the amount to transfer from the user interface.
- Subtract the amount from the savings account, and determine the new balance.
- Read the fee schedule to determine the transaction fee for a savings account with the given balance.
- Subtract the transaction fee from the savings account.
- Add the amount of the transfer to the checking account.
- Commit the transaction (unit of work).
Figure 1. Using a Single Database in a Transaction
To set up such an application, :
- Create the tables for the savings account, checking account and transaction fee schedule in the same database.
- If physically remote, set up the database server to use the appropriate communications protocol.
- If physically remote, catalog the node and the database to identify the database on the database server.
- Precompile your application program to specify a type 1 connection; that is, specify CONNECT(1) on the PREP command.
Parent topic: Distributed Relational Database Architecture