In the DB2 database manager, a transaction is commonly referred to as a unit of work. A unit of work is a recoverable sequence of operations within an application process, and is the basic building block used by the database manager to ensure that a database is in a consistent state. Any reading or writing to the database is done within a unit of work. A point of consistency (or commit point) is a time when all recoverable data that an application accesses is consistent with related data.
For example, a bank transaction might involve the transfer of funds from a savings account to a checking account. After the application subtracts the amount from the savings account, the two accounts are inconsistent; they are not consistent again until the amount is added to the checking account. When both steps are completed, the point of consistency is reached, and the changes can be committed and are made available to other applications.
A unit of work starts when the first SQL statement is issued against the database. The application must end the unit of work by issuing either a COMMIT or a ROLLBACK statement. The COMMIT statement makes permanent all changes made within a unit of work, whereas the ROLLBACK statement removes these changes from the database. If the application ends normally without either of these statements, the unit of work is automatically committed. If it ends abnormally while in the middle of a unit of work, the unit of work is automatically rolled back. Once issued, a COMMIT or ROLLBACK cannot be stopped. With some multi-threaded applications, if the application ends normally without either of these statements, the unit of work is automatically rolled back. Similarly on some operating systems (such as Windows platforms), if the application ends normally without either of these statements, the unit of work is automatically rolled back. The recommendation when writing your applications is to always explicitly COMMIT or ROLLBACK your completed unit of work.
In the above banking example, only if both requests are processed successfully, should the application direct the database manager to commit the changes. If either request is not processed successfully, the updates should be rolled back, leaving both tables as they were before the transaction began. This ensures that requests are neither lost nor duplicated.
The following topics provide additional information:
For information on creating applications using distributed databases, see the Embedded SQL Programming Guide and the CLI Guide and Reference manuals.