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
Using a Single Database in a Transaction
To set up such an application, you must:
  1. Create the tables for the savings account, checking account and transaction fee schedule in the same database.
  2. If physically remote, set up the database server to use the appropriate communications protocol.
  3. If physically remote, catalog the node and the database to identify the database on the database server.
  4. Precompile your application program to specify a type 1 connection; that is, specify CONNECT(1) on the PREP command.