About Transactions

This topic includes the following sections:

•	What Is a Transaction?

•	Benefits of Using Transactions

•	Example of a Global Transaction

•	What Is the Oracle Tuxedo Transaction Manager (TM)?

•	How the System Tracks Distributed Transaction Processing

•	How the System Uses a Two-Phase Commit to Commit Transactions

Note:

For information about using transactions in an Oracle Tuxedo CORBA environment, refer to Using CORBA Transactions.

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:

 

Procedure for Any Transaction	Procedure for Bank Withdrawal Example
1. Verify the activity to be performed	1. Verify that a withdrawal will be made
2. Perform the work of the transaction	2. Withdraw a specified amount from the account
3. Create a permanent record of the completed work	3. Update the record of the balance of the account

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.

 

Table 4‑1 ACID Properties of Oracle Tuxedo Transactions

This Property . . .	Means That . . .
Atomicity	A transaction is a discrete unit of work: all constituent operations must either succeed or fail. These operations may include queuing messages, updating databases, and displaying the results of a transaction on a screen.
Consistency	A transaction must either (a) leave the system in a correct state or (b) abort. If a transaction cannot achieve a stable state, it must return to its initial state.
Isolation	The behavior of a transaction is not affected by other transactions being executed simultaneously. A transaction must serialize all access to shared resources and guarantee that concurrent programs do not corrupt each other’s operations.
Durability	The effects of a committed transaction are permanent. Even if the system fails, the changes resulting from a transaction are permanent and durable.

How a Transaction Succeeds or Fails

Whether a transaction succeeds or fails depends on the requirements of atomicity.

 

If . . .	Then . . .
Any operation within the transaction fails for any reason	• 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.
All operations within the transaction succeed	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:

•	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

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:

•	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.

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.

 

Table 4‑2 Actions Performed by the Transaction Manager

When . . .	The Transaction Manager . . .
The application launches a transaction	Assigns a global transaction identifier (GTRID) to the transaction.
Other processes communicate with the process that launched the transaction	Tracks those communication partners.
The RM is accessed as part of the work of the transaction	Passes the appropriate GTRID to the RM so the RM can monitor which database records are being accessed for the transaction.
The application signals that a transaction is to be committed	Performs a two-phase commit protocol. Specifically, it: (a) contacts communication partners during Phase 1, (b) logs the successful outcome of Phase 1, and (c) contacts partners in Phase 2.
The application indicates that the transaction is to be aborted	Executes a rollback procedure.
A failure occurs	Executes a recovery procedure.

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:

1.	Install Oracle database 10g client (or later), create link libclntsh.so for libclntsh.so.x.x (for example, libclntsh.so.10.1) and set LD_LIBRARY_PATH for link libclntsh.so on Linux platform.

2.	Set UBBCONFIG(5) TLOGDEVICE or DMCONFIG(5) DMTLOGDEV using the following format: "DB:Oracle_XA: ….". For example:

TLOGDEVICE="DB:Oracle_XA:ORACLE_XA+SqlNet=ORCL+ACC=P/scott/tiger"

DMTLOGDEV="DB:Oracle_XA:ORACLE_XA+SqlNet=ORCL+ACC=P/scott/tiger"

3.	Run tmloadcf to generate TUXCONFIG.

4.	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>

Note the followings.

•	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.

•	Below are the rules for TLOGNAME in UBBCONFIG.

•	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.

•	Do not start TLOGNAME with "QS" or "TUX" because they are reserved by Tuxedo. DBA should guarantee that.

•	Uppercase TLOGNAME when using TLOG2DB.

•	Different platforms should share different database schemas.

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.

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

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.

1.	Client_1 initiates (with tpbegin()) a transaction.

2.	Client_1 invokes (with tpcall()) Service_A, which:

a.	Is infected with the transaction

b.	Executes its operations

c.	Calls tpreturn()

d.	Completes its work for the transaction

3.	Client_1 invokes (with tpcall()) Service_B, which:

a.	Is infected with the transaction

b.	Executes its operations

c.	Calls tpreturn()

d.	Completes its work for the transaction

4.	Client_1 invokes (with tpcall()) Service_C, which:

a.	Is infected with the transaction

b.	Executes its operations

c.	Calls tpreturn()

d.	Completes its work for the transaction

5.	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

•	?$paratext>? on page 5‑1

•	?$paratext>? on page 5‑9

•	?$paratext>? on page 5‑12

•	“Writing Global Transactions” in Programming Oracle Tuxedo ATMI Applications Using C

•	“What You Can Do Using the ATMI” in Introducing Oracle Tuxedo ATMI

•	For more information about using transactions in a Oracle Tuxedo CORBA environment, refer to Using CORBA Transactions