|
|
This topic includes the following sections:
This topic provides the information that programmers need to write transactional applications for the WebLogic Enterprise (WLE) system. Before you begin, you should read Introducing Transactions.
WLE provides a Transaction Service that supports transactions in CORBA, EJB, and RMI applications. The Transaction Service provides:
About the Transaction Service
For CORBA Java, EJB, and RMI applications, WLE also provides Sun Microsystems, Inc.'s javax.transaction
package, which implements the Java Transaction API (JTA) for Java applications. For more information about the JTA, see Sun Microsystem's Java Transaction API (JTA) Specification (version1.0.1). For more information about the UserTransaction object that applications use to demarcate transaction boundaries, see UserTransaction API.
This topic includes the following sections:
Capabilities and Limitations
These sections describe the capabilities and limitations of the Transaction Service that supports CORBA and EJB applications:
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. WLE 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, or the remote implementation of UserTransaction
that EJB or RMI clients use, delegate the actual responsibility of transaction coordination to transaction manager on the server.
For CORBA applications, the CORBAservices Object Transaction Service specification states that a client can choose to propagate a transaction context either implicitly or explicitly. WLE provides implicit propagation. Explicit propagation is strongly discouraged.
Note:
For EJB and RMI applications, only implicit propagation is supported for clients.
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.
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 CORBAservices Object 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.
WLE 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.
WLE implements the flat transaction model. Nested transactions are not supported.
WLE supports remote clients invoking methods on server objects in different WLE domains in the same transaction.
Remote clients with multiple connections to the same WLE domain may make invocations to server objects on these separate connections within the same transaction.
For C++ (but not Java) applications, WLE supports native clients invoking methods on server objects in the WLE domain. In addition, WLE supports server objects invoking methods on other objects in the same or in different processes within the same WLE domain.
A client application can have only one active bootstrap object and TransactionCurrent
object within a single domain. WLE does not support exporting or importing transactions to or from remote WLE 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.
The Transaction Service relates to various transaction processing servers, interfaces, protocols, and standards in the following ways:
Lightweight Clients with Delegated Commit
Transaction Propagation (CORBA Only)
Transaction Integrity
Transaction Termination
Flat Transactions
Interoperability Between Remote Clients and the WLE Domain
Intradomain and Interdomain Interoperability
Network Interoperability
Relationship of the Transaction Service to Transaction Processing
Servers using the WLE Transaction Service can make invocations on other BEA TUXEDO Application-to-Transaction Monitor Interface (ATMI) server processes in the same domain. WLE does not support the following:
The Open Group Resource Managers are Resource Managers that can be involved in a distributed transaction by allowing their two-phase commit protocol to be controlled via The Open Group XA interface. WLE supports interaction with The Open Group Resource Managers.
Open Systems Interconnect Transaction Processing (OSI TP) is the transactional protocol defined by the International Organization for Standardization (ISO). WLE does not support interactions with OSI TP transactions.
Systems Network Architecture (SNA) LU 6.2 is a transactional protocol defined by IBM. WLE does not support interactions with LU 6.2 transactions.
ODMG-93 is a standard defined by the Object Database Management Group (ODMG) that describes a portable interface to access Object Database Management Systems. WLE does not support interactions with ODMG transactions.
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 WLE is built upon the existing BEA TUXEDO transaction management system, it inherits the TUXEDO capabilities for keeping applications running.
WLE supports multithreaded clients for non-transactional clients. For transactional clients, WLE supports only single-threaded client implementation. Clients cannot make transaction requests concurrently in multiple threads.
The following constraints apply to the Transaction Service:
Process Failure
Multithreaded Transaction Client Support
General Constraints
As a result, the objects that were infected by (or participating in) the rolled back transaction get their states cleared by WLE a little later. Therefore, no other client can infect these objects with a different transaction until WLE 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 "Server Description File" in the CORBA Java Programming Reference or "Implementation Configuration File (ICF)" in the CORBA C++ Programming Reference.
This topic includes the following sections:
Transaction Service in CORBA Applications
These sections describe how WLE 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.
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 TransactionCurrent Object
If an application requires the Transaction Service APIs with the extensions, it should issue a com.beasys.Tobj.TransactionCurrent.narrow() (in Java) or Tobj::TransactionCurrent::_narrow() (in C++) on the object pointer returned from step 2 above.
This topic includes the following sections:
These sections describe the CORBA-based components of the CosTransactions
modules that WLE implements to support the Transaction Service. For more information about these components, see Chapter 10 of the CORBAservices: Common Object Services Specification.
Listing 2-1 shows the supported data types.
Listing 2-1
Data Types Supported by the Transaction Service
enum Status { StatusActive, Data Types
StatusMarkedRollback,
StatusPrepared,
StatusCommitted,
StatusRolledBack,
StatusUnknown,
StatusNoTransaction,
StatusPreparing,
StatusCommitting,
StatusRollingBack
};
// This information comes from CORBAservices: Common Object
// Services Specification, p. 10-15. Revised Edition:
// March 31, 1995. Updated: March 1997. Used with permission by OMG.
Listing 2-2 shows the supported exceptions in IDL code.
Listing 2-2 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 CORBAservices: Common Object Services Specification, pages 10-16, 19, 20. Revised Edition: March 31, 1995. Updated: March 1997. Used with permission by OMG.
Exception |
Description |
---|---|
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-3).
Listing 2-3
Current
Interface idl
// Current transaction }; // This information comes from CORBAservices: Common Object Current Interface
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);
// Services Specification, p. 10-18. Revised Edition:
// March 31, 1995. Updated: November 1997. Used with permission by // OMG
Table 2-2 provides a description of the Current transaction methods.
Note: This information comes from CORBAservices: Common Object Services Specification, pages 10-18, 19, 20. Revised Edition: March 31, 1995. Updated: November 1997. Used with permission by OMG.
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-4 shows the Control
interface, which is defined in the CosTransactions
module.
Listing 2-4
Control
Interface
interface Control { // This information comes from CORBAservices: Common Object Control Interface
Terminator get_terminator()
raises(Unavailable);
Coordinator get_coordinator()
raises(Unavailable);
};
// Services Specification, p. 10-21. Revised Edition:
// March 31, 1995. Updated: November 1997. Used with permission by // OMG.
The Control interface is used only in conjunction with the suspend and resume methods.
The org.omg.CosTransactions.TransactionalObject interface (in Java) or CosTransactions::TransactionalObject (in C++) is used by an object to indicate that it is transactional. By supporting this interface, an object indicates that it wants the transaction context associated with the client thread to be propagated on requests to the object. However, this interface is no longer needed. For details on transaction policies that need to be set to infect objects with transactions, see "Server Description File" in the CORBA Java Programming Reference or "Implementation Configuration File (ICF)" in the CORBA C++ Programming Reference.
The CosTransactions module defines the TransactionalObject interface (shown in Listing 2-5). The org.omg.CosTransactions.TransactionalObject interface defines no methods. It is simply a marker.
Listing 2-5 TransactionalObject Interface
interface TransactionalObject {
};
// This information comes from CORBAservices: Common Object
// Services Specification, p. 10-30. Revised Edition:
// March 31, 1995. Updated: November 1997. Used with permission by // OMG.
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.
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 com.beasys.Tobj module (in Java) or Tobj module (in C++).
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.
This interface supports all the methods of the Current interface in the CosTransactions module and is described in "Java Bootstrap Object Programming Reference" in the CORBA Java Programming Reference or in "C++ Bootstrap Object Programming Reference" in the CORBA C++ Programming Reference. Additionally, this interface supports APIs to open and close the Resource Manager.
Listing 2-6 shows the TransactionCurrent interface, which is defined in the Tobj module.
Listing 2-6 TransactionCurrent Interface
Interface TransactionCurrent: CosTransactions::Current {
void open_xa_rm()
raises(RMfailed);
void close_xa_rm()
raises(Rmfailed);
}
Table 2-3 describes APIs that are specific to the Resource Manager. For more information about these APIs, see the CORBA Java Programming Reference or the CORBA C++ Programming Reference.
Consider the following guidelines when integrating transactions into your WLE CORBA client/server applications:
You cannot start a new transaction if an existing transaction is already active. (You may start a new transaction if you first suspend the existing one; however, the object that suspends the transaction is the only object that can subsequently resume the transaction.)
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.
The WLE EJB Container provides a Transaction Service that supports the two types of transactions in WLE EJB applications:
Transaction Service in EJB Applications
For an introduction to transaction management in EJB applications, see Transactions in WLE EJB Applications, and Transactions Sample EJB Code.
WLE provides a Transaction Service that supports transactions in WLE RMI applications. In RMI applications, the client or server application makes explicit method invocations on the UserTransaction
object to begin, commit, and roll back transactions.
For more information about UserTransaction
methods, see UserTransaction API. For an introduction to transaction management in RMI applications, see Transactions in WLE RMI Applications, and Transactions Sample RMI Code.
This topic includes the following sections:
Transaction Service in RMI Applications
UserTransaction API
WLE provides Sun Microsystems, Inc.'s javax.transaction
package, which implements the Java Transaction API (JTA) for Java applications. The javax.UserTransaction
interface supports transaction management for CORBA Java applications as well as for bean-managed transactions in EJB applications. For more information about the JTA, see Sun Microsystem's Java Transaction API (JTA) Specification (version1.0.1). For a detailed description of the javax.transaction
interface, see the package description in the WLE Javadoc.
Table 2-4 describes the methods in the UserTransaction
object.
UserTransaction Methods
Table 2-5 describes exceptions thrown by methods of the UserTransaction object.
|
Copyright © 1999 BEA Systems, Inc. All rights reserved.
|