Oracle Tuxedo supports the Object Management Group Common Object Request Broker (CORBA) in C++, in compliance with the The Common Object Request Broker: Architecture and Specification, Revision 2.4.2, January 2001.Oracle Tuxedo supports the CORBA services Object Transaction Service (OTS). Oracle Tuxedo provides a C++ interface to the OTS and is based on the OTS. The OTS is accessed through the org.omg.CosTransactions.Current environmental object. For information about using the TransactionCurrent environmental object, see the “CORBA Bootstrapping Programming Reference” in the CORBA Programming Reference.
Note: Oracle Tuxedo CORBA supports distributed transactions and the two-phase commit protocol for enterprise applications. A distributed transaction is a transaction that updates multiple resource managers (such as databases) in a coordinated manner. The two-phase commit protocol (2PC) is a method of coordinating a single transaction across one or more resource managers. It guarantees data integrity by ensuring that transactional updates are committed in all of the participating databases, or are fully rolled back out of all the databases, reverting to the state prior to the start of the transaction.Figure 1‑1 illustrates transactions in an Oracle CORBA application.
2. A client application begins a transaction using the Tobj::TransactionCurrent::begin() operation, and issues a request to the CORBA interface through the TP Framework. All operations on the CORBA interface execute within the scope of a transaction.
• The client application commits the current transaction using the Tobj::TransactionCurrent::commit() operation. This operation ends the transaction and starts the processing of the operation. The transaction is committed only if all of the participants in the transaction agree to commit.
3. The Tobj::TransactionCurrent:commit() operation causes the TP Framework to call the transaction manager to complete the transaction.
1. The client application uses the ORB::resolve_initial_references() operation to get a FactoryFinder object for the Oracle Tuxedo domain.
Note: The TransactionFactory returns objects that adhere to the standard CORBA Services Transaction Service interfaces instead of the Oracle delegated interfaces. This means that a third-party client can use their ORB’s resolve_initial_references() function to get the TransactionFactory from an Oracle Tuxedo CORBA server and use stubs generated from standard OMG IDL to act on the instances returned.
3. The client application then uses the create() operation on the TransactionFactory to begin a transaction and issues a request to the CORBA interface through the TP Framework.
4. From the Control object returned from the create() operation, the client application uses the get_terminator() operation to get the transaction Terminator interface.
5. The client application then uses the commit() or rollback() operation on the Terminator interface to end or abort the transaction. The commit() operation causes the TP Framework to call the transaction manager to complete the transaction.
• The client application commits the current transaction using the Terminator::commit() operation. This operation ends the transaction and starts the processing of the operation. The transaction is committed only if all of the participants in the transaction agree to commit.
Note: For more information on INS, see the “CORBA Bootstrapping Programming Reference” in the CORBA Programming Reference.
•
• If the student exceeds the maximum number of credits the student can take, the server application returns a TooManyCredits user exception to the client application. The client application provides a brief message explaining that the request was rejected. The client application then rolls back the transaction.Figure 1‑2 illustrates how the Transactions sample application works.Figure 1‑2 Transactions Sample Application
• Nonfatal. If the registration for a course fails because the course is not in the database, or because the student is already registered for the course, the server application returns the numbers of those courses to the client application. The decision to roll back the transaction lies with the user of the client application (and the Transaction client application code rolls back the transaction automatically in this case).
• Fatal. If the registration for a course fails because the student exceeds the maximum number of credits he or she can take, the server application generates a CORBA exception and returns it to the client. The decision to roll back the transaction also lies with the client application.Thus, the Transactions sample application also shows how to implement user-defined CORBA exceptions. For example, if the student tries to register for a course that would exceed the maximum number of courses for which the student can register, the server application returns the TooManyCredits exception. When the client application receives this exception, the client application rolls back the transaction automatically.
Note: For information about how transactions are implemented in Oracle Tuxedo CORBA applications, see the Transactions Sample in the Oracle Tuxedo online documentation.The Transactions sample application is used to demonstrate these development steps. The source files for the Transactions sample application are located in the \samples\corba\university directory of the Oracle Tuxedo software. For information about building and running the Transactions sample application, see the Transactions Sample in the Oracle Tuxedo online documentation.For the Transactions sample application, you would define in OMG IDL the Registrar interface and the register_for_courses() operation. The register_for_courses() operation has a parameter, NotRegisteredList, which returns to the client application the list of courses for which registration failed. If the value of NotRegisteredList is empty, then the client application commits the transaction. You also need to define the TooManyCredits user exception.Listing 1‑1 includes the OMG IDL for the Transactions sample application.Listing 1‑1 OMG IDL for the Transactions Sample ApplicationTransaction policies are used on a per-interface basis. During design, it is decided which interfaces within an Oracle Tuxedo application will handle transactions. Table 1‑1 describes the CORBA transaction policies.
Table 1‑1 CORBA Transaction Policies The interface is not transactional. However, requests made to this interface within a scope of a transaction are allowed. The AUTOTRAN parameter, specified in the UBBCONFIG file for this interface, is ignored. The interface is not transactional. Objects created for this interface can never be involved in a transaction. The Oracle Tuxedo system generates an exception (INVALID_TRANSACTION) if an interface with this policy is involved in a transaction. During development, you decide which interfaces will execute in a transaction by assigning transaction policies. You specify transaction policies in the Implementation Configuration File (ICF). A template ICF file is created by the genicf command. For more information about the ICFs, see “Implementation Configuration File (ICF)” in the CORBA Programming Reference.In the Transactions sample application, the transaction policy of the Registrar interface is set to always.When using transactions in server applications, you need to write methods that implement the interface’s operations. In the Transactions sample application, you would write a method implementation for the register_for_courses() operation.If your Oracle Tuxedo application uses a database, you need to include in the server application code that opens and closes an XA resource manager. These operations are included in the Server::initialize() and Server::release() operations of the Server object. Listing 1‑2 shows the portion of the code for the Server object in the Transactions sample application that opens and closes the XA resource manager.
Note: For a complete example of a CORBA server application that implements transactions, see the Transactions Sample in the Oracle Tuxedo online documentation.
2. Begins a transaction by invoking the Tobj::TransactionCurrent::begin() operation on the TransactionCurrent object.
3. Invokes operations on the object. In the Transactions sample application, the client application invokes the register_for_courses() operation on the Registrar object, passing a list of courses.Listing 1‑3 shows the portion of the CORBA C++ client applications in the Transactions sample application that illustrates the development steps for transactions.
Note: The sample code shown in Listing 1‑3 illustrates how to use the Oracle bootstrapping mechanism. For information on how to use the INS bootstrapping mechanism, see the “CORBA Bootstrapping Programming Reference” in the CORBA Programming Reference.CORBA::Object_var var_transaction_current_oref =
Bootstrap.resolve_initial_references(“TransactionCurrent”);
CosTransactions::Current_var transaction_current_oref=
CosTransactions::Current::_narrow(var_transaction_current_oref.in());
//Begin the transaction
var_transaction_current_oref->begin();
try {
//Perform the operation inside the transaction
pointer_Registar_ref->register_for_courses(student_id, course_number_list);
...
//If operation executes with no errors, commit the transaction:
CORBA::Boolean report_heuristics = CORBA_TRUE;
var_transaction_current_ref->commit(report_heuristics);
}
catch (...) {
//If the operation has problems executing, rollback the
//transaction. Then throw the original exception again.
//If the rollback fails, ignore the exception and throw the
//original exception again.
try {
var_transaction_current_ref->rollback();
}
catch (...) {
TP::userlog("rollback failed");
}
throw;
}
• In the GROUPS section:
• In the OPENINFO parameter, include the information needed to open the resource manager for the database. You obtain this information from the product documentation for your database. Note that the default version of the com.beasys.Tobj.Server.initialize method automatically opens the resource manager.
• In the CLOSEINFO parameter, include the information needed to close the resource manager for the database. By default, the CLOSEINFO parameter is empty.
• Specify the TMSNAME and TMSCOUNT parameters to associate the XA resource manager with a specified server group.
• In the SERVERS section, define a server group that includes both the server application that includes the interface and the server application that manages the database. This server group needs to be specified as transactional.
• Include the pathname to the transaction log (TLOG) in the TLOGDEVICE parameter. For more information about the transaction log, see Chapter 5, “Administering Transactions.”Listing 1‑4 includes the portions of the configuration file that define this information for the Transactions sample application.