![]() |
![]() |
![]() |
![]() |
![]() |
Note: For information about using transactions in an Oracle Tuxedo CORBA environment, refer to Using CORBA Transactions.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 transaction coordinator is a software module that executes the logic to manage a transaction among all participating resources.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.
• 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.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.
1. Calls tpbegin() to begin the transaction
3. Calls tpcommit() to end the transactionAs 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.Table 4‑2 summarizes the actions taken by the Transaction Manager on behalf of each transaction.
Assigns a global transaction identifier (GTRID) to the transaction. Passes the appropriate GTRID to the RM so the RM can monitor which database records are being accessed for the 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.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 ManagementThe 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.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.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.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:
3.
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.
• You can only write TLOG to an Oracle database. Third party databases are not supported.
•
• 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.
• Do not start TLOGNAME with "QS" or "TUX" because they are reserved by Tuxedo. DBA should guarantee that.
• A two-phase commit is an algorithm used to ensure the integrity of a committing transaction.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 InfectionIn 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.)
1. Client_1 initiates (with tpbegin()) a transaction.
2. Client_1 invokes (with tpcall()) Service_A, which:
a. Is infected with the transaction
c. Calls tpreturn()
3. Client_1 invokes (with tpcall()) Service_B, which:
a. Is infected with the transaction
c. Calls tpreturn()
4. Client_1 invokes (with tpcall()) Service_C, which:
a. Is infected with the transaction
c. Calls tpreturn()
5. Client_1 initiates (with tpcommit()) the commitment process.
•
•
• For more information about using transactions in a Oracle Tuxedo CORBA environment, refer to Using CORBA Transactions