e-docs > Tuxedo > Using CORBA Transactions > Transaction Service |
Using CORBA Transactions |
Transaction Service
This topic includes the following sections:
This topic provides the information that programmers need to write transactional CORBA applications for the BEA Tuxedo system. Before you begin, you should read Introducing Transactions.
About the Transaction Service
BEA Tuxedo provides a Transaction Service that supports transactions in CORBA applications. The Transaction Service provides an implementation of the CORBA Services Transaction Service that is described in the OMG CORBA Services Transaction Service Specification. This specification defines the interfaces for an object service that provides transactional functions.
Capabilities and Limitations
This topic includes the following sections:
These sections describe the capabilities and limitations of the Transaction Service that supports CORBA applications.
Lightweight Clients with Delegated Commit
A lightweight client runs on a single-user, unmanaged desktop system that has irregular availability. Owners may turn their desktop systems off when they are not in use. These single-user, unmanaged desktop systems should not be required to perform network functions such as transaction coordination. In particular, unmanaged systems should not be responsible for ensuring atomicity, consistency, isolation, and durability (ACID) properties across failures for transactions involving server resources. BEA Tuxedo CORBA remote clients are lightweight clients.
The Transaction Service allows lightweight clients to do a delegated commit, which means that the Transaction Service allows lightweight clients to begin and terminate transactions while the responsibility for transaction coordination is delegated to a transaction manager running on a server machine. Client applications do not require a local transaction server. The remote TransactionCurrent implementation that CORBA clients use delegates the actual responsibility of transaction coordination to transaction manager on the server.
Support for Third-Party Clients Using INS
In BEA Tuxedo release 8.0 and later, the CORBA Interoperable Naming Service (INS) is supported. Therefore, clients that implement the CORBA services Object Transaction Service (OTS) can communicate with BEA Tuxedo CORBA servers and initiate and terminate transactions. Using INS, any third-party client ORB that can compile the standard OTS IDL files and produce usable stub files can interact with the BEA Tuxedo CORBA transaction manager. However, such interaction is limited because the transaction coordination interfaces that would allow a third-party ORB to become a resource manager are not supported. Only BEA provided resource managers and/or XA compliant resource managers can participate in the coordination of a transaction. Further, the BEA provided and XA compliant resource managers can participate in transaction coordination only if they use the XA protocols—not the CORBA services OTS protocols—for transaction coordination.
In summary, a third-party client ORB can be used to initiate a transaction, and the client can request the rollback or commit of the transaction, however, the client ORB cannot participate in the coordination of the two-phase commit protocol using the CORBA services OTS.
Multithreaded Transaction Client Support
In release 8.0, BEA Tuxedo CORBA supports multithreaded clients for nontransactional clients and transactional clients.
Transaction Propagation (CORBA Only)
For CORBA applications, the OMG CORBA Services Transaction Service specification states that a client can choose to propagate a transaction context either implicitly or explicitly. BEA Tuxedo provides implicit propagation. Explicit propagation is strongly discouraged.
Objects that are related to transaction contexts that are passed around using explicit transaction propagation should not be mixed with implicit transaction propagation APIs. It should be noted, however, that explicit propagation does not place any constraints on when transactional methods can be processed. There is no guarantee that all transactional methods will be completed before the transaction is committed.
Transaction Integrity
Checked transaction behavior provides transaction integrity by guaranteeing that a commit will not succeed unless all transactional objects involved in the transaction have completed the processing of their transactional requests. If implicit transaction propagation is used, the Transaction Service provides checked transaction behavior that is equivalent to that provided by the request/response interprocess communication models defined by The Open Group. For CORBA applications, for example, the Transaction Service performs reply checks, commit checks, and resume checks, as described in the OMG CORBA Services Transaction Service Specification.
Unchecked transaction behavior relies completely on the application to provide transaction integrity. If explicit propagation is used, the Transaction Service does not provide checked transaction behavior and transaction integrity is not guaranteed.
Transaction Termination
BEA Tuxedo CORBA allows transactions to be terminated only by the client that created the transaction.
Note: The client may be a server object that requests the services of another object.
Flat Transactions
BEA Tuxedo CORBA implements the flat transaction model. Nested transactions are not supported.
Interoperability Between CORBA Remote Clients and the BEA Tuxedo Domain
BEA Tuxedo CORBA supports remote clients invoking methods on server objects in different BEA Tuxedo domains in the same transaction.
Remote CORBA clients with multiple connections to the same BEA Tuxedo domain may make invocations to server objects on these separate connections within the same transaction.
Intradomain and Interdomain Interoperability
BEA Tuxedo CORBA supports native clients invoking methods on server objects in the BEA Tuxedo domain. In addition, BEA Tuxedo supports server objects invoking methods on other objects in the same or in different processes within the same BEA Tuxedo domain.
In BEA Tuxedo applications, transactions can span multiple domains as long as factory-based routing is properly configured across multiple domains. To support transactions across multiple domains, you must configure the factory_finder.ini file to identify factory objects that are used in the current (local) domain but that are resident in a different (remote) domain. For more information, see Using the BEA Tuxedo Domains Component
.Network Interoperability
A client application can have only one active Bootstrap object and TransactionCurrent object within a single domain. BEA Tuxedo CORBA does not support exporting or importing transactions to or from remote BEA Tuxedo domains.
However, transactions can encompass multiple domains in a serial fashion. For example, a server with a transaction active in Domain A can communicate with a server in Domain B within the context of that same transaction.
Relationship of the Transaction Service to Transaction Processing
The Transaction Service relates to various transaction processing servers, interfaces, protocols, and standards in the following ways:
Process Failure
The Transaction Service monitors the participants in a transaction for failures and inactivity. The BEA Tuxedo system provides management tools for keeping the application running when failures occur. Because BEA Tuxedo CORBA is built upon the BEA Tuxedo transaction management system, it inherits the BEA Tuxedo capabilities for keeping applications running.
General Constraints
The following constraints apply to the Transaction Service:
As a result, the objects that were infected by (or participating in) the rolled back transaction get their states cleared by BEA Tuxedo a little later. Therefore, no other client can infect these objects with a different transaction until BEA Tuxedo clears the states of these objects. This condition exists for a very short amount of time and is typically not noticeable in a production application. A simple workaround for this race condition is to try the appropriate operation after a short (typically a 1-second) delay.
No error or exception will be returned to the client because it is a one-way method invocation. However, the method on the server object will not be executed, and an appropriate error message will be written to the log. Clients may make one-way method invocations within the context of a transaction to server objects with the IGNORE transaction policy. In this case, the method on the server object will be executed, but not in the context of a transaction. For more information about the transaction policies, see "Implementation Configuration File (ICF)" in the CORBA Programming Reference.
Transaction Service in CORBA Applications
This topic includes the following sections:
These sections describe how BEA Tuxedo implements the OTS, with particular emphasis on the portion of the CORBAservices Object Transaction Service that is described as implementation-specific. They describe the OTS application programming interface (API) that you use to begin or terminate transactions, suspend or resume transactions, and get information about transactions.
Getting Initial References to the TransactionCurrent Object Using the Bootstrap Object
To use the TransactionCurrent object to access the Transaction Service API and the extension to the Transaction Service API as described later in this chapter, an application needs to complete the following operations:
Getting Initial References to the TransactionFactory Object Using INS
BEA Tuxedo also supports the use of the CORBA Interoperable Naming Service (INS) by third-party clients to obtain initial transaction object references. INS uses the ORB::resolve_initial_references() operation.
Listing 2-1 shows an example of how a client application, using INS, gets an object reference to the TransactionFactory object. For a complete code example, see the client application in the University Sample.
Listing 2-1 Code Example for a Client Application that Uses INS
// Get the factory finder from the ORB:
CORBA::Object_var v_fact_finder_oref =
orb->resolve_initial_references("FactoryFinder");
// Narrow the factory finder :
Tobj::FactoryFinder_var v_fact_finder_ref =
Tobj::FactoryFinder::_narrow(v_fact_finder_oref.in());
// Get the TransactionFactory from the FactoryFinder
CORBA::Object_var v_txn_fac_oref =
v_fact_finder_ref->find_one_factory_by_id(
"IDL:omg.org/CosTransactions/TransactionFactory:1.0");
// Narrow the TransactionFactory object reference
CosTransactions::TransactionFactory_var v_txn_fac_ref =
CosTransactions::TransactionFactory::_narrow(
v_txn_fac_oref.in());
For more information about using the ORB::resolve_initial_references() operation, see "CORBA Bootstrapping Programming Reference" in the CORBA Programming Reference.
CORBA Transaction Service API
This topic includes the following sections:
These sections describe the CORBA-based components of the CosTransactions modules that BEA Tuxedo implements to support the Transaction Service. For more information about these components, see the OMG CORBA Services Transaction Service Specification, Version 1.1, May 2000.
Data Types
Listing 2-2 shows the supported data types.
Listing 2-2 Data Types Supported by the Transaction Service
enum Status {
StatusActive,
StatusMarkedRollback,
StatusPrepared,
StatusCommitted,
StatusRolledBack,
StatusUnknown,
StatusNoTransaction,
StatusPreparing,
StatusCommitting,
StatusRollingBack
};
// This information comes from the OMG Transaction Service
// Specification, Version 1.1, May 2000. Used with permission
// of the OMG.
Exceptions
Listing 2-3 shows the supported exceptions in IDL code.
Listing 2-3 Exceptions Supported by the Transaction Service
// Heuristic exceptions
exception HeuristicMixed {};
exception HeuristicHazard {};
// Other transaction-specific exceptions
exception SubtransactionsUnavailable {};
exception NoTransaction {};
exception InvalidControl {};
exception Unavailable {};
Table 2-1 describes the exceptions.
Note: This information comes from the OMG CORBA Services Transaction Service Specification, Version 1.1, May 2000. Used with permission of the OMG.
Current Interface The Current interface defines methods that allow a client of the Transaction Service to explicitly manage the association between threads and transactions. The Current interface also defines methods that simplify the use of the Transaction Service for most applications. These methods can be used to begin and end transactions, to suspend and resume transactions, and to obtain information about the current transaction. The CosTransactions module defines the Current interface (shown in Listing 2-4). Listing 2-4 Current Interface IDL Table 2-2 provides a description of the Current transaction methods. Note: This information was taken from the OMG CORBA Services Transaction Service Specification, Version 1.1, May 2000. Used with permission of the OMG.
// Current transaction
interface Current : CORBA::Current {
void begin()
raises(SubtransactionsUnavailable);
void commit(in boolean report_heuristics)
raises(
NoTransaction,
HeuristicMixed,
HeuristicHazard
);
void rollback()
raises(NoTransaction);
void rollback_only()
raises(NoTransaction);
Status get_status();
string get_transaction_name();
void set_timeout(in unsigned long seconds);
Control get_control();
Control suspend();
void resume(in Control which)
raises(InvalidControl);};
// This information comes from the OMG Transaction Service
// Specification, Version 1.1, May 2000. Used with permission
// of the OMG.
Control Interface The Control interface allows a program to explicitly manage or propagate a transaction context. An object that supports the Control interface is implicitly associated with one specific transaction. Listing 2-5 shows the Control interface, which is defined in the CosTransactions module. Listing 2-5 Control Interface The Control interface is used only in conjunction with the suspend and resume methods. Terminator Interface The Terminator interface supports operations to commit or roll back a transaction. Typically, these operations are used by the transaction originator. An implementation of the Transaction Service may restrict the scope in which a Terminator can be used; at a minimum, it can be used within a single thread. Listing 2-6 shows the Terminator interface. Listing 2-6 Terminator Interface Table 2-3 describes the Terminator interface methods.
interface Control {
Terminator get_terminator()
raises(Unavailable);
Coordinator get_coordinator()
raises(Unavailable);
};// This information comes from the OMG Transaction Service
// Specification, Version 1.1, May 2000. Used with permission
// of the OMG.interface Terminator {
void commit(in boolean report_heuristics)
raises(
HeuristicMixed,
HeuristicHazard
);
void rollback();
};// This information was taken from the OMG Transaction Service
// Specification, Version 1.1, May 2000. Used with permission
// of the OMG.
TransactionalObject Interface In BEA Tuxedo release 8.0 and later, the CosTransactions::TransactionalObject is no longer used by an object to indicate that it is transactional. If an interface inherits from a TransactionalObject and the ICF indicates a different transaction policy, a warning is issued. The TransactionalObject is not used for any other purpose. For details on transaction policies that need to be set to infect objects with transactions, see "Implementation Configuration File (ICF)" in the CORBA Programming Reference. The CosTransactions module defines the TransactionalObject interface (shown in Listing 2-7). This interface defines no methods; it is simply a marker. Listing 2-7 TransactionalObject Interface TransactionFactory Interface The TransactionFactory interface is provided to allow the transaction originator to begin a transaction. This interface defines two operations, create and recreate, which create a new representation of a top-level transaction. A TransactionFactory is located using the FactoryFinder interface of the life cycle service and not by the resolve_initial_reference() operation on the ORB interface. Listing 2-8 shows the TransactionFactory interface. Note: The Control recreate method of the TransactionFactory interface is not supported. Listing 2-8 TransactionFactory Interface Table 2-4 describes the TransactionFactory interface methods.
interface TransactionalObject {
};// This information was taken from the OMG Transaction Service
// Specification, Version 1.1, May 2000. Used with permission
// of the OMG.interface TransactionFactory {
Control create(in unsigned long time_out);
Control recreate(in PropagationContext ctx);
};// This information was taken from the OMG Transaction Service
// Specification, Version 1.1, May 2000. Used with permission
// of the OMG.
Other CORBAservices Object Transaction Service Interfaces All other CORBAservices Object Transaction Service interfaces are not supported. Note that the Current interface described earlier is supported only if it has been obtained from the Bootstrap object. The Control interface described earlier is supported only if it has been obtained using the get_control and the suspend methods on the Current object. CORBA Transaction Service API Extensions This topic describes specific extensions to the CORBAservices Transaction Service API described earlier. The APIs in this topic enable an application to open or close an Open Group resource manager. The following APIs help facilitate participation of resource managers in a distributed transaction by allowing their two-phase commit protocol to be controlled via The Open Group XA interface. The following definitions and interfaces are defined in the Tobj module. Exception The following exception is supported: exception RMfailed {}; A request raises this exception to report that an attempt to open or close a resource manager failed. TransactionCurrent Interface This interface supports all the methods of the Current interface in the CosTransactions module and is described in "C++ Bootstrap Object Programming Reference" in the CORBA Programming Reference. Additionally, this interface supports APIs to open and close the resource manager. Listing 2-9 shows the TransactionCurrent interface, which is defined in the Tobj module. Listing 2-9 TransactionCurrent Interface Interface TransactionCurrent: CosTransactions::Current { Table 2-5 describes APIs that are specific to the resource manager. For more information about these APIs, see the CORBA Programming Reference.
void open_xa_rm()
raises(RMfailed);
void close_xa_rm()
raises(Rmfailed);
}
Notes on Using Transactions in BEA Tuxedo CORBA Applications
Consider the following guidelines when integrating transactions into your BEA Tuxedo CORBA client/server applications:
Java
org.omg.CORBA.OBJ_ADAPTER
C++
CORBA::OBJ_ADAPTER
If a client that is in a transaction attempts to invoke an operation on an object that is currently in a different transaction, the client application receives the following error message:
Java
org.omg.CORBA.INVALID_TRANSACTION
C++
CORBA::INVALID_TRANSACTION
If the object is invoked outside a transaction, the object does not incur the overhead of scoping a transaction for reading data. This way, regardless of whether the object is invoked within a transaction, all the object's write operations are handled transactionally.
UserTransaction API
This topic includes the following sections:
UserTransaction Methods
Table 2-6 describes the methods in the UserTransaction object.
Exceptions Thrown by UserTransaction Methods
Table 2-7 describes exceptions thrown by methods of the UserTransaction object.