A transaction is a set of related actions. A global transaction is a set of related actions that span multiple programs and resource managers. In this topic, whenever we use the term transaction, we are referring to a global transaction.

A simple example of a transaction is a withdrawal from a bank account, which can be described as a set of actions that changes the state of an account balance (by reducing it). For this transaction, the system must execute a procedure that consists of three operations:

These steps are performed by a discrete software module created expressly for the purpose of executing this transaction. The module must also include or use code that launches and ends the transaction. If the code sections that launch and end the transaction are not part of the main transaction software module, then they are usually packaged together in a separate module.

A transaction coordinator is a software module that executes the logic to manage a transaction among all participating resources.

• What Are the ACID Properties?
  
• How a Transaction Succeeds or Fails
  

The Oracle Tuxedo system, including its communication APIs and protocols, is designed to support the use of transactions. The Oracle Tuxedo communication calls, which make it easy to create transactions, are indispensable tools for writing distributed applications.

By using transactions you can:

• Create distributed applications easily
• Commit the effects of your communications as a single unit
• Quickly manage potential problems that may occur in a distributed environment, such as machine, program, or network failures
• Undo work, when errors occur, in a simple, programmatic way

An e-retailer uses a service called CUST_ORDER. When a customer places an order through the company’s Web site, the CUST_ORDER service performs two operations:

• It updates the company’s database of orders.
• It sends the new order to the shipping department, where it is put on a queue, awaiting fulfillment.

The company wants to be sure that the CUST_ORDER service adheres to the principle of atomicity: whenever CUST_ORDER is executed, both the database update and the enqueueing of the customer request on the shipping department queue must be completed successfully. To make sure that the CUST_ORDER service always handles customer orders with atomicity, the client that invokes CUST_ORDER associates its request with a global transaction.

To associate a service with a global transaction, a client:

1. Calls tpbegin() to begin the transaction
2. Issues a service request
3. Calls tpcommit() to end the transaction

As part of a global transaction, the operation is performed as a single unit of work. When the CUST_ORDER service is invoked, the server is propagated with the client’s transaction. The two resulting operations, accessing the order database and enqueuing the order to the shipping queue, become part of the client’s transaction.

If either operation fails for any reason, whether due to a system error or an application error, the work of the transaction is undone or rolled back. In other words, the transaction is returned to its initial state.

If both operations succeed, however, the client commits the transaction. In other words, it formally signals that the effects of the transaction should be made permanent: the order database is updated permanently and the order sent to the shipping department is kept in that department’s queue.

A resource manager (RM) is a data repository, such as a database management system or the Application Queuing Manager, with tools for accessing the data. The Oracle Tuxedo system uses one or more RMs to maintain the state of an application. For example, bank records in which account balances are maintained are kept in an RM. When the state of the application changes through a service that allows a customer to withdraw money from an account, the new balance in the account is recorded in the appropriate RM.

The Oracle Tuxedo system helps you manage transactions involving resource managers that support the XA interface. To coordinate all the operations performed and all the modules affected by a transaction, the Oracle Tuxedo system plays the role of the Transaction Manager (TM).

The TM coordinates global transactions involving system-wide resources. Local resource managers (RMs) are responsible for individual resources. The Transaction Manager Server (TMS) begins, commits, and aborts transactions involving multiple resources. The application code uses the normal embedded SQL interface to the RM to perform reads and updates. The TMS uses the XA interface to the RM to perform the work of a global transaction.

The following table summarizes the actions taken by the Transaction Manager on behalf of each transaction.

Oracle Tuxedo transactions can be used in a distributed architecture: a local machine involved in a transaction can communicate with a remote machine which may, in turn, communicate with another remote machine. The work of transactions executed in this type of arrangement is referred to as distributed transaction processing.

Because the system must constantly maintain enough information about a transaction to be able to roll it back (that is, to restore it to its initial state) at any moment, tracking distributed transaction processing (DTP) can be a complex task. To perform this task successfully, the Oracle Tuxedo system stores tracking information about all the participants in a transaction in a dedicated file called a transaction log, or TLOG.

The following figure shows an application in which two Transaction Managers (TMs) are being used. Both TMs record tracking data in the same TLOG.

Before committing a transaction, the TM must repeatedly answer the question of whether to proceed. If necessary, the TM makes the decision to roll back.

• How the System Uses Global Transaction Identifiers (GTRIDs) for Tracking
  
• How the System Uses a Transaction Log (TLOG) for Tracking
  

A two-phase commit is an algorithm used to ensure the integrity of a committing transaction.

To understand how this algorithm works, consider the following sample scenario. A group of six friends wants to rent a house for a one-week vacation. No member of the group can afford to pay more than one sixth of the rent; if any of the six cannot participate, then the house cannot be rented.

1. In Phase 1 of this project, the organizer of the vacation contacts each person to verify availability and collect a sixth of the rent. If the organizer learns that even one person cannot participate, she contacts every member of the group, individually, to notify him or her that the house cannot be rented. If, however, each member of the group confirms availability and pays one sixth of the rent, the Phase 1 concludes successfully.
2. In Phase 2 of the project, the organizer notifies each member of the group that the vacation will take place as planned.

A two-phase transaction commit works in much the same way as the vacation planning project.

1. In Phase 1, the transaction coordinator contacts potential participants in the transaction. The participants all agree to make the results of the transaction permanent, but do not do so immediately. The participants log information to disk to ensure they can complete Phase 2. If all the participants agree to commit, the coordinator logs that agreement and the outcome is decided. The recording of this agreement in the log ends Phase 1.
2. In Phase 2, the coordinator informs each participant of the decision, and they permanently update their resources.

• How the System Handles Transaction Infection
  
• How the ATMI Protects a Transaction’s Integrity Before a Two-Phase Commit