Transaction Processing

In this section:

How to:

You are familiar with individual data source operations that insert, update, or delete data source segment instances. However, most applications are concerned with "real-world" transactions, like transferring funds or fulfilling a sales order, that require several data source operations. These data source operations may access several data sources, and may be issued from several procedures. We call such a collection of data source operations a logical transaction, also known as a logical unit of work.

This and related topics describe how Maintain ensures transaction integrity at the application level. At the data source level, each database management system (DBMS) implements transaction integrity in its own way; see your DBMS vendor's documentation for DBMS-specific information. For FOCUS data sources, this DBMS-specific information is presented in Ensuring Transaction Integrity for FOCUS Data Sources. For DB2, you can find some suggested strategies for writing Maintain transactions to DB2 data sources in Ensuring Transaction Integrity for DB2 Data Sources. For many other types of data sources, you can also apply the strategies described in Ensuring Transaction Integrity for DB2 Data Sources, changing DBMS-specific details when necessary.


Top of page

Example: Describing a Transfer of Funds as a Logical Transaction

A banking application would define a transfer of funds from one account to another as one logical transaction comprising two update operations:


Top of page

x
Procedure: How to Process a Logical Transaction

To process a logical transaction, follow these steps:

  1. DBMS requirements. Your data sources' database management system (DBMS) may require that you perform some tasks to enable transaction integrity; see your database vendor's documentation for information. You can set some native DBMS parameters through FOCUS; for more information, see the FOCUS Interface manual for your DBMS.

    For FOCUS data sources, you must set the COMMIT environment variable to ON, and to issue a USE command to specify which FOCUS Database Server will manage concurrent access to the data source. For more information, see Ensuring Transaction Integrity for FOCUS Data Sources.

  2. Develop the transaction logic. Code the data source commands and related logic that read from the data sources, write to the data sources, and evaluate the success of each data source command.
  3. Define the transaction boundary. Code a COMMIT command, and any other supporting commands, to define the transaction's boundary. For more information, see Defining a Transaction.
  4. Evaluate the transaction's success. Test the FocCurrent transaction variable to determine whether the transaction was successfully written to the data source, and then branch accordingly. For more information, see Determining Whether a Transaction Was Successful.

Top of page

x
Why Is Transaction Integrity Important?

The advantage of describing a group of related data source commands as one logical transaction is that the transaction is valid and written to the data source only if all of its component commands are successful. When you attempt to commit a transaction, you are ensured that if part of the transaction fails, none of the transaction will be written to the data source. This is called transaction integrity .

When is transaction integrity important? Whenever a group of commands are related and are only meaningful within the context of the group. In other words, whenever the failure of any one command in the transaction at commit time would invalidate the entire transaction.

Transaction integrity is an all-or-nothing proposition: either all of the transaction is written to the data source when you commit it, or all of it is rolled back.



Example: Why Transaction Integrity Is Essential to a Bank

Consider a banking application that transfers funds from a savings account to a checking account. If the application successfully subtracts the funds from the savings account, but is interrupted by a system problem before it can add the funds to the checking account, the money would "disappear," unbalancing the bank's accounts.

The two update commands (subtracting and adding funds) must be described as parts of a single logical transaction, so that the subtraction and addition updates are not written to the data source independently of each other.


Information Builders