Managing Transactions


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| PDF Files \| Contact \| Glossary

Tuxedo Documentation \| Introducing BEA Tuxedo ATMI \| Local Topics \| Previous Topic \| Next Topic \| Contents

A powerful feature of the BEA Tuxedo system is the ability to manage transactions for database applications that support the XA interface. Transactions simplify the writing of distributed applications. They allow your application to cope more easily with a large set of problems that can occur in distributed environments, such as machine, program, and network failures.

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 communication and the work done by the remote machines is part of the transaction, and integrity must be maintained. Keeping track of distributed transaction processing (DTP) can be a complex task because the system must maintain enough information about a transaction to be able to roll it back (that is, to undo it) at any moment.

Transaction Management

To keep track of the participants in a transaction, the BEA Tuxedo system creates a transaction log. To maintain the state of an application as represented by the contents of the computer's memory, the BEA Tuxedo system uses one or more resource managers (or RM; a collection of information and processes for accessing it, such as a database management system). To coordinate all the operations performed and all the modules affected by a transaction, the BEA Tuxedo system uses a Transaction Manager (TM), which directs the actions of the RMs. Together, TMs and RMs maintain the atomicity of a distributed transaction.

Coordinating Operations with a Transaction Manager Server (TMS)

The BEA Tuxedo Transaction Manager (TM) is responsible for coordinating 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 server uses an embedded SQL interface to the RM to read and update the database accessed by the server group. The TMS and RMs use the XA interface to perform all or none of the resource work in a global transaction.

Tracking Participants with a Transaction Log (TLOG)

A global transaction is logged in the transaction log (TLOG) only when it is in the process of being committed. The TLOG records the reply from the global transaction participants at the end of the first phase of a 2-phase-commit protocol. A TLOG record indicates that a global transaction should be committed; no TLOG record is written for those transactions that are to be rolled back. In the first phase, or pre-commit, each Resource Manager must commit to performing the transaction request. Once all parties commit, transaction management commits and completes the transaction. If either tasks 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.

Note: Customers using the Domains feature should note 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 in the TLOG, in addition to Domains-specific information.