HOME | SITE MAP | SEARCH | CONTACT | GLOSSARY | PDF FILES | WHAT'S NEW
JAVA REFERENCE | TABLE OF CONTENTS | PREVIOUS TOPIC | NEXT TOPIC
|
|
|
BEA WebLogic Enterprise 4.2 Developer Center |
|
HOME | SITE MAP | SEARCH | CONTACT | GLOSSARY | PDF FILES | WHAT'S NEW |
||
|
JAVA REFERENCE | TABLE OF CONTENTS | PREVIOUS TOPIC | NEXT TOPIC |
||
This chapter contains the following topics:
The WebLogic Enterprise system provides the following:
javax.transaction package, which implements the Java Transaction API (JTA).
This chapter describes how the WebLogic Enterprise software implements the OTS; in particular, that portion of the CORBAservices Object Transaction Service that is described as implementation-specific. This chapter provides the information that programmers need to write transactional applications for the WebLogic Enterprise system. It describes the OTS application programming interface (API) that you use to begin or terminate transactions, suspend or resume transactions, and get information about transactions.
For information about JTA, refer to the following:
javax.transaction package description in the Java API Reference.
The following sections describe the capabilities and limitations of the Transaction Service.
A lightweight client runs on a single-user, unmanaged desktop system that has irregular availability; that is, the 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 like 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. WebLogic Enterprise remote clients are lightweight clients.
The Transaction Service allows lightweight clients to do delegated commit. Delegated commit 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. The lightweight client does not need a local CORBAservices Object Transaction Service transaction manager.
The CORBAservices Object Transaction Service specification states that a client can choose to propagate transaction context either implicitly or explicitly. This implementation of the CORBAservices Object Transaction Service provides implicit propagation. Explicit propagation is strongly discouraged.
Objects that are related to transaction context 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. The Transaction Service performs 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.
This implementation of the CORBAservices Object Transaction Service 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.
This implementation of the CORBAservices Object Transaction Service implements the flat transaction model.
This implementation of the CORBAservices Object Transaction Service does not support remote clients invoking methods on server objects in different WebLogic Enterprise domains in the same transaction.
Remote clients with multiple connections to the same WebLogic Enterprise domain may not make invocations to server objects on these separate connections within the same transaction. An The WebLogic Enterprise implementation of the CORBAservices Object Transaction Service supports native clients invoking methods on server objects in the WebLogic Enterprise domain. In addition, server objects invoking methods on other objects in the same or in different processes in the same WebLogic Enterprise domain is supported.
This implementation of the CORBAservices Object Transaction Service does not support the export or import of transactions to or from remote WebLogic Enterprise domains.
This section describes the relationship of the Transaction Service to various transaction processing servers, interfaces, protocols, and standards, as follows:
Capabilities and Limitations
Lightweight Clients with Delegated Commit
Transaction Propagation
Transaction Integrity
reply checks, commit checks, and resume checks, as described in the CORBAservices Object Transaction Service Specification.
Transaction Termination
Flat Transactions
Interoperability Between Remote Clients and the WebLogic Enterprise Domain
org.omg.CORBA.NO_PERMISSION standard system exception is returned to the client.
Intradomain Interoperability
Network Interoperability
Relationship of the Transaction Service to Transaction Processing
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. This implementation of the CORBAservices Object Transaction Service 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). The WebLogic Enterprise implementation of the CORBAservices Object Transaction Service does not support interactions with OSI TP transactions.
Systems Network Architecture (SNA) LU 6.2 is a transactional protocol defined by IBM. The WebLogic Enterprise implementation of the CORBAservices Object Transaction Service does not support interactions with LU 6.2 transactions.
The Transaction Service monitors the participants in a transaction for failures and inactivity. One of the features that distinguishes the BEA TUXEDO system from other distributed application environments is the management tools for keeping the application running when failures occur. Because the WebLogic Enterprise implementation of the CORBAservices Object Transaction Service is built upon the existing BEA TUXEDO transaction management system, it inherits the capabilities of the BEA TUXEDO system for keeping applications running.
The WebLogic Enterprise implementation of the CORBAservices Object Transaction Service supports single-threaded implementations only. Specifically, a client with an active transaction cannot make requests for the same transaction on multiple threads. However, it is possible to have multiple transactions serially active at the same time in a single thread.
The CORBAservices Object Transaction Service OMG IDL is described in detail in Chapter 10 of the CORBAservices: Common Object Services Specification. The WebLogic Enterprise implementation of the CORBAservices Object Transaction Service supports a functionally complete subset of the CORBAservices Object Transaction Service OMG IDL interfaces. For details, see the section "Transaction Service API" on page 7-9 The following constraints apply:
Process Failure
Multithreaded Support
OMG Interface Definition Language (IDL)
General Constraints
NEVER, OPTIONAL, or ALWAYS transaction policies. No error or exception will be returned to the client because it is a oneway method invocation; however, the method on the server object will not be executed. Also, an appropriate error message will be written to the log. Clients may make oneway method invocations within the context of a transaction to server objects having 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 further details on the transaction policies, see Chapter 2, "Server Description File."
To access the Transaction Service API and the extension to the Transaction Service API as described later in this chapter, an application needs to issue the following commands.
Getting Initial References to the TransactionCurrent Object
resolve_initial_reference("TransactionCurrent") method
on the Bootstrap object. The invocation returns a standard CORBA object
pointer. For a description of this Bootstrap object method, see Chapter 4,
"Bootstrap Object."
The following sections describe the portions of the CosTransactions modules that are based on CORBA that are implemented in the WebLogic Enterprise software to support the Transaction Service. For further details, refer to Chapter 10 of the CORBAservices: Common Object Services Specification.
The definitions and interfaces supported by the Transaction Service in the WebLogic Enterprise software are as follows:
Listing 7-1 shows the supported data types.
Data Types
Listing 7-1
Data Types Supported by the Transaction Service
enum Status { StatusActive,
StatusMarkedRollback,
StatusPrepared,
StatusCommitted,
StatusRolledBack,
StatusUnknown,
StatusNoTransaction
StatusPreparing,
StatusCommitting,
StatusRollingBack
};
// This information is taken from CORBAservices: Common Object
// Services Specification, p. 10-15. Revised Edition:
// March 31, 1995. Updated: March 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.
The org.omg.CosTransactions.TransactionalObject interface 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 the sections "Server Description File Syntax" on page 2-3 and "TransactionalObject Interface Not Enforced" on page 3-4.
The CosTransactions module defines the TransactionalObject interface (shown in Listing 7-2). The org.omg.CosTransactions.TransactionalObject interface defines no methods. It is simply a marker.
Listing 7-2 TransactionalObject Interface
interface TransactionalObject {
};// This information is taken 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 section describes specific extensions to the COBRAservices Transaction Service API described earlier. The APIs in this section 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.
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 as described in the Java API Reference. Additionally, this interface supports APIs to open and close the resource manager.
The Tobj module defines the TransactionCurrent interface, as shown in Listing 7-3.
Listing 7-3 TransactionCurrent Interface
Interface TransactionCurrent: CosTransactions::Current {
void open_xa_rm()
raises(RMfailed);
void close_xa_rm()
raises(Rmfailed);
}
Table 7-1 describes APIs that are specific to the resource manager. For more information about these APIs, see the Java API Reference.
