Table of Contents Previous Next PDF

About Transactions

About Transactions
This topic includes the following sections:
What Is a Transaction?
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?
When a transaction such as a bank withdrawal is performed, it is imperative that all its constituent operations either succeed or fail together. Consider the problems that can occur if one operation in a transaction succeeds while another operation in the same transaction fails: a bank that allows a customer to withdraw money without recording the reduced balance in an updated account record will not stay in business for long!
A transaction that adheres to the rule that all constituent operations either succeed or fail is characterized by atomicity. The Oracle Tuxedo system requires all transactions to be characterized by atomicity and three related attributes: consistency, isolation, and durability. These four attributes are known collectively as the ACID properties of transactions performed within the Oracle Tuxedo system.
Table 4‑1 shows the ACID of Oracle Tuxedo Transactions.
How a Transaction Succeeds or Fails
Whether a transaction succeeds or fails depends on the requirements of atomicity.
The transaction aborts, that is, it terminates abruptly.
The transaction rolls back, that is, it undoes its own work and restores the state of the enterprise to its pre-transaction state. For example, after an attempt to withdraw money from a bank account fails and is rolled back, the bank account contains the same amount of money it contained before the transaction, and the record of the account balance shows the same amount that it showed before the transaction.
The client commits the transaction. In other words, it formally signals that it is ready to terminate and the effects of the transaction should be preserved: the order database is updated permanently and the order sent to the shipping department is kept as a permanent record in that department’s queue.
Benefits of Using Transactions
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:
Example of a Global Transaction
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:
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:
Calls tpbegin() to begin the transaction
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.
What Is the Oracle Tuxedo Transaction Manager (TM)?
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.
Table 4‑2 summarizes the actions taken by the Transaction Manager on behalf of each transaction.
Tracks those communication partners.
Passes the appropriate GTRID to the RM so the RM can monitor which database records are being accessed for the transaction.
How the System Tracks Distributed Transaction Processing
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.
Figure 4‑1 shows an application in which two Transaction Managers (TMs) are being used. Both TMs record tracking data in the same TLOG.
Figure 4‑1 Transaction Management
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
The Oracle Tuxedo system tracks the flow of all transactions being executed within a distributed system, including those being executed concurrently. When it is time to commit a transaction, the coordinator must know which RMs have participated in the transaction and, therefore, needs to be able to distinguish among transactions. For this reason the Oracle Tuxedo system assigns a global transaction identifier, or GTRID to each transaction.
The Oracle Tuxedo system communicates with any RM accessed by an application through the XA interface. The RMs track transactions by assigning local transaction identifiers, and map global identifiers to local identifiers.
How the System Uses a Transaction Log (TLOG) for Tracking
A global transaction is recorded in the transaction log (TLOG) only when it is in the process of being committed. At the end of the first phase of a two-phase commit protocol, the TLOG records the reply from the global transaction participants.
The existence of a TLOG record indicates that a global transaction should be committed; no TLOG records are written for transactions that are to be rolled back.
In the first “pre-commit” phase, each resource manager must commit to performing the transaction request. If all parties commit, transaction management performs the second phase: it commits and completes the transaction. If either task fails because of an application or system failure, both tasks fail and the work performed is undone or “rolled back” to its initial state.
The TMS that coordinates global transactions uses the TLOG file. Each machine should have its own TLOG.
If you are using the Domains component in your application, keep in mind that the Domains gateway performs the functions of the TMS in Domains groups. However, Domains uses its own transaction log containing information similar to that recorded in the TLOG, in addition to Domains-specific information.
Writing TLOG to an Oracle Database
If you want to write TLOG into an Oracle database, you must do the following steps:
Install Oracle database 10g client (or later), create link for (for example, and set LD_LIBRARY_PATH for link on Linux platform.
Set UBBCONFIG(5) TLOGDEVICE or DMCONFIG(5) DMTLOGDEV using the following format: "DB:Oracle_XA: ….". For example:
Run tmloadcf to generate TUXCONFIG.
Create TLOG using the tmadmin and dmadmin commands. Below is an example to create TLOG using tmadmin. After TLOG command crlog is done, a table is created; the value that TLOGNAME defines in UBBCONFIG becomes the table name.
$ tmadmin
$ crlog -m <Machine>
You can only write TLOG to an Oracle database. Third party databases are not supported.
There is no need for you to create TLOG using tmadmin command crdl.
TLOGDEVICE/DMTLOGDEV points to Oracle database schema, which Tuxedo treats it as a database storage device.
TLOGNAME in UBBCONFIG must not be empty. If multiple TLOG files are stored in the same schema of database, DBA should guarantee that TLOGNAME is unique for each TLOG, and Tuxedo exclusively accesses the database table that TLOGNAME specifies for the TLOG.
How the System Uses a Two-Phase Commit to Commit Transactions
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.
A two-phase transaction commit works in much the same way as the vacation planning project.
How the System Handles Transaction Infection
Any application module called by another module to participate in a transaction is said to be transactionally infected. Once an application module is infected, the Oracle Tuxedo system tracks all participants to determine which of them should be involved in the two-phase commit. Figure 4‑2 shows how the system tracks participants.
Figure 4‑2 Transactional Infection
In the preceding figure, Client 1 begins the transaction and calls three services: A, B, and C. Because they have been called into the transaction, Services A, B, and C are transactionally infected. All work performed by servers A, B, and C is part of the transaction begun by Client 1. All work is performed as one unit; either it is performed together and is successful, or it fails and is rolled back by calling tpabort. If the transaction fails, it returns to its initial state and its effects of the transaction on resource managers are undone. (Resource managers that are not transactionally aware and those that are accessed from outside the transaction cannot be rolled back.)
How the ATMI Protects a Transaction’s Integrity Before a Two-Phase Commit
All work performed by each resource involved in a transaction must be completed before a two-phase commit is begun. The ATMI ensures that all the work of the transaction is stopped when it is time for the two-phase commit protocol to begin.
The following step-by-step description of a transaction shows how the ATMI stops a transaction process before a two-phase commit.
Client_1 initiates (with tpbegin()) a transaction.
Client_1 invokes (with tpcall()) Service_A, which:
Is infected with the transaction
Calls tpreturn()
Client_1 invokes (with tpcall()) Service_B, which:
Is infected with the transaction
Calls tpreturn()
Client_1 invokes (with tpcall()) Service_C, which:
Is infected with the transaction
Calls tpreturn()
Client_1 initiates (with tpcommit()) the commitment process.
If, during the transaction, an invoked service is performing another service, or is involved in an open conversation, the ATMI tracks that activity and prevents the application from proceeding to the commitment process until the activity is complete.
The ATMI guarantees that the transaction is committed only if all invoked services have performed their transaction work successfully. When all work has been performed successfully, the Transaction Manager informs the resource managers that all updates made during the transaction are permanent.
See Also
“Writing Global Transactions” in Programming Oracle Tuxedo ATMI Applications Using C
“What You Can Do Using the ATMI” in Introducing Oracle Tuxedo ATMI

Copyright © 1994, 2017, Oracle and/or its affiliates. All rights reserved.