Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	http://www.oracle.com/technology/documentation/index.html   |   Site Map   |   Search   |   PDF Files   |   Contact   |   Glossary
WebLogic Enterprise Doc Home   |   Transaction Topics   |   Previous Topic   |   Next Topic   |   Contents   |   Index

This topic includes the following sections:

• About the Transaction Service

• Capabilities and Limitations

• Transaction Service in CORBA Applications

• Transaction Service in EJB Applications

• Transaction Service in RMI Applications

• UserTransaction API

This topic provides the information that programmers need to write transactional applications for the WebLogic Enterprise system. Before you begin, you should read Introducing Transactions.

WebLogic Enterprise provides a Transaction Service that supports transactions in CORBA, EJB, and RMI applications. The Transaction Service provides:

• An implementation of the CORBAservices Object Transaction Service (OTS) that is described in Chapter 10 of the CORBAservices: Common Object Services Specification. This specification defines the interfaces for an object service that provides transactional functions.

• In the WebLogic Enterprise EJB container, an implementation of the transaction services described in the Enterprise JavaBeans Specification 1.1, published by Sun Microsystems, Inc.

For CORBA Java, EJB, and RMI applications, WebLogic Enterprise also provides the javax.transaction package, from Sun Microsystems, Inc., which implements the Java Transaction API (JTA) for Java applications. For more information about the JTA, see the Java Transaction API (JTA) Specification (version 1.0.1), published by Sun Microsystems, Inc. For more information about the UserTransaction object that applications use to demarcate transaction boundaries, see UserTransaction API.

This topic includes the following sections:

• Lightweight Clients with Delegated Commit

• Transaction Propagation (CORBA Only)

• Transaction Integrity

• Transaction Termination

• Flat Transactions

• Interoperability Between Remote Clients and the WebLogic Enterprise Domain

• Intradomain and Interdomain Interoperability

• Network Interoperability

• Relationship of the Transaction Service to Transaction Processing

• Process Failure

• Multithreaded Transaction Client Support

• General Constraints

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. WebLogic Enterprise 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. WebLogic Enterprise 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.

WebLogic Enterprise 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.

WebLogic Enterprise implements the flat transaction model. Nested transactions are not supported.

WebLogic Enterprise supports 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 make invocations to server objects on these separate connections within the same transaction.

For C++ (but not Java) applications, WebLogic Enterprise supports native clients invoking methods on server objects in the WebLogic Enterprise domain. In addition, WebLogic Enterprise supports server objects invoking methods on other objects in the same or in different processes within the same WebLogic Enterprise domain.

In WebLogic Enterprise 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 "Configuring Multiple Domains (WebLogic Enterprise System)" in the Administration Guide.

A client application can have only one active bootstrap object and TransactionCurrent object within a single domain. WebLogic Enterprise does not support exporting or importing transactions to or from remote WebLogic Enterprise 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:

• Support for BEA Tuxedo ATMI servers. Servers using the WebLogic Enterprise Transaction Service can make invocations on other BEA Tuxedo Application-to-Transaction Monitor Interface (ATMI) server processes in the same domain. In addition, ATMI services can invoke CORBA objects in both transactional and non-transactional contexts, both within the same domain and across domains via a TDOMAINS gateway. However, WebLogic Enterprise does not support remote clients or native clients invoking ATMI services in the WebLogic Enterprise domain.

• Support for The Open Group XA interface. 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. WebLogic Enterprise supports interaction with The Open Group Resource Managers.

• Support for the OSI TP protocol. Open Systems Interconnect Transaction Processing (OSI TP) is the transactional protocol defined by the International Organization for Standardization (ISO). WebLogic Enterprise does not support interactions with OSI TP transactions.

• Support for the LU 6.2 protocol. Systems Network Architecture (SNA) LU 6.2 is a transactional protocol defined by IBM. WebLogic Enterprise does not support interactions with LU 6.2 transactions.

• Support for the ODMG standard. ODMG-93 is a standard defined by the Object Database Management Group (ODMG) that describes a portable interface to access Object Database Management Systems. WebLogic Enterprise does not support interactions with ODMG transactions.

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 WebLogic Enterprise is built upon the existing BEA Tuxedo transaction management system, it inherits the Tuxedo capabilities for keeping applications running.

WebLogic Enterprise supports multithreaded clients for non-transactional clients. For transactional clients, WebLogic Enterprise supports only single-threaded client implementation. Clients cannot make transaction requests concurrently in multiple threads.

The following constraints apply to the Transaction Service:

• In WebLogic Enterprise, a client or a server object cannot invoke methods on an object that is infected with (or participating in) another transaction. The method invocation issued by the client or the server will return an exception.

• For CORBA applications, a server application object using transactions from the WebLogic Enterprise Transaction Service library requires the TP Framework functionality. For more information about the TP Framework, see "TP Framework" in the CORBA C++ Programming Reference.

• For CORBA applications, a return from the rollback method on the Current object is asynchronous. Similarly, for EJB and RMI applications, a return from the rollback method on the UserTransaction object is asynchronous.

  As a result, the objects that were infected by (or participating in) the rolled back transaction get their states cleared by WebLogic Enterprise a little later. Therefore, no other client can infect these objects with a different transaction until WebLogic Enterprise 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.

• In WebLogic Enterprise, clients using third-party implementations of the CORBAservices Object Transaction Service (for CORBA applications) or the Java Transaction API (for Java applications) are not supported.

• In WebLogic Enterprise CORBA applications, clients may not make one-way method invocations within the context of a transaction to server objects having the NEVER, OPTIONAL, or ALWAYS transaction policies.

  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:

• Getting Initial References to the TransactionCurrent Object

• CORBA Transaction Service API

• CORBA Transaction Service API Extensions

• Notes on Using Transactions in WebLogic Enterprise CORBA Applications

These sections describe how WebLogic Enterprise 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:

1. Create a Bootstrap object. For more information about creating a Bootstrap object, see "C++ Bootstrap Object Programming Reference" in the CORBA C++ Programming Reference.

2. Invoke the 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 the CORBA C++ Programming Reference.

3. If an application requires only the Transaction Service APIs, it should issue an org.omg.CosTransactions.Current.narrow() (in Java) or CosTransactions::Current::_narrow() (in C++) on the object pointer returned from step 2 above.

   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:

• Data Types

• Exceptions

• Current Interface

• Control Interface

• TransactionalObject Interface

These sections describe the CORBA-based components of the CosTransactions modules that WebLogic Enterprise 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.

enum Status {

       StatusActive,
       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.

// 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.

Table 2-1 Exceptions Supported by the Transaction Service

Exception	Description
HeuristicMixed	A request raises this exception to report that a heuristic decision was made and that some relevant updates have been committed and others have been rolled back.
HeuristicHazard	A request raises this exception to report that a heuristic decision was made, that the disposition of all relevant updates is not known, and that for those updates whose disposition is known, either all have been committed or all have been rolled back. Therefore, the HeuristicMixed exception takes priority over the HeuristicHazard exception.
SubtransactionsUnavailable	This exception is raised for the Current interface begin method if the client already has an associated transaction.
NoTransaction	This exception is raised for the Current interface rollback and rollback_only methods if there is no transaction associated with the client thread.
InvalidControl	This exception is raised for the Current interface resume method if the parameter is not valid in the current execution environment.
Unavailable	This exception is raised for the Control interface get_terminator and get_coordinator methods if the Control interface cannot provide the requested object.

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-3).

// 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 CORBAservices: Common Object 
// 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.

Table 2-2 Transaction Methods in the Current Object

Method	Description
begin	Creates a new transaction. The transaction context of the client thread is modified so that the thread is associated with the new transaction. If the client thread is currently associated with a transaction, the SubtransactionsUnavailable exception is raised. If the client thread cannot be placed in transaction mode due to an error while starting the transaction, the standard system exception INVALID_TRANSACTION is raised. If the call was made in an improper context, the standard system exception BAD_INV_ORDER is raised.
commit	If there is no transaction associated with the client thread, the NoTransaction exception is raised. If the call was made in an improper context, the standard system exception BAD_INV_ORDER is raised. If the system decides to roll back the transaction, the standard exception TRANSACTION_ROLLEDBACK is raised and the thread's transaction context is set to null. A HeuristicMixed exception is raised to report that a heuristic decision was made and that some relevant updates have been committed and others have been rolled back. A HeuristicHazard exception is raised to report that a heuristic decision was made, and that the disposition of all relevant updates is not known; for those updates whose disposition is known, either all have been committed or all have been rolled back. The HeuristicMixed exception takes priority over the HeuristicHazard exception. If a heuristic exception is raised or the operation completes normally, the thread's transaction exception context is set to null. If the operation completes normally, the thread's transaction context is set to null.
rollback	If there is no transaction associated with the client thread, the NoTransaction exception is raised. If the call was made in an improper context, the standard system exception BAD_INV_ORDER is raised. If the operation completes normally, the thread's transaction context is set to null.
rollback_only	If there is no transaction associated with the client thread, the NoTransaction exception is raised. Otherwise, the transaction associated with the client thread is modified so that the only possible outcome is to roll back the transaction.
get_status	If there is no transaction associated with the client thread, the StatusNoTransaction value is returned. Otherwise, this method returns the status of the transaction associated with the client thread.
get_transaction_name	If there is no transaction associated with the client thread, an empty string is returned. Otherwise, this method returns a printable string describing the transaction (specifically, the XID as specified by The Open Group). The returned string is intended to support debugging.
set_timeout	This method modifies a state variable associated with the target object that affects the time-out period associated with transactions created by subsequent invocations of the begin method. The initial transaction timeout value is 300 seconds. Calling set_timeout() with an argument value larger than zero specifies a new timeout value. Calling set_timeout() with a zero argument sets the timeout value back to the default of 300 seconds. After calling set_timeout(), transactions created by subsequent invocations of begin are subject to being rolled back if they do not complete before the specified number of seconds after their creation. Note: The initial transaction timeout value is 300 seconds. If a transaction is started via AUTOTRAN instead of the begin method, then the timeout value is determined by the TRANTIME value in the WebLogic Enterprise configuration file. For more information, see Administering Transactions.
get_control	If the client is not associated with a transaction, a null object reference is returned. Otherwise, a Control object is returned that represents the transaction context currently associated with the client thread. This object may be given to the resume method to reestablish this context.
suspend	If the client thread is not associated with a transaction, a null object reference is returned. If the associated transaction is in a state such that the only possible outcome of the transaction is to be rolled back, the standard system exception TRANSACTION_ROLLEDBACK is raised and the client thread becomes associated with no transaction. If the call was made in an improper context, the standard system exception BAD_INV_ORDER is raised. The caller's state with respect to the transaction is not changed. Otherwise, an object is returned that represents the transaction context currently associated with the client thread. The same client can subsequently give this object to the resume method to reestablish this context. In addition, the client thread becomes associated with no transaction. Note: As defined in The Common Object Request Broker: Architecture and Specification, Revision 2.2, February 1998, the standard system exception TRANSACTION_ROLLEDBACK indicates that the transaction associated with the request has already been rolled back or has been marked to roll back. Thus, the requested method either could not be performed or was not performed because further computation on behalf of the transaction would be fruitless.
resume	If the client thread is already associated with a transaction which is in a state such that the only possible outcome of the transaction is to be rolled back, the standard system exception TRANSACTION_ROLLEDBACK is raised and the client thread becomes associated with no transaction. If the call was made in an improper context, the standard system exception BAD_INV_ORDER is raised. If the system is unable to resume the global transaction because the caller is currently participating in work outside any global transaction with one or more resource managers, the standard system exception INVALID_TRANSACTION is raised. If the parameter is a null object reference, the client thread becomes associated with no transaction. If the parameter is valid in the current execution environment, the client thread becomes associated with that transaction (in place of any previous transaction). Otherwise, the InvalidControl exception is raised. Note: See suspend for a definition of the standard system exception TRANSACTION_ROLLEDBACK.

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-4 shows the Control interface, which is defined in the CosTransactions module.

interface Control {
       Terminator get_terminator()
              raises(Unavailable);
       Coordinator get_coordinator()
              raises(Unavailable);
};

// This information comes from CORBAservices: Common Object 
// 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.

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.

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.

Table 2-3 Resource Manager APIs for the Current Interface

Method	Description
open_xa_rm	This method opens The Open Group Resource Manager to which this process is linked. A RMfailed exception is raised if there is a failure while opening the resource manager. Any attempts to invoke this method by remote clients or the native clients raises the standard system exception NO_IMPLEMENT.
close_xa_rm	This method closes The Open Group Resource Manager to which this process is linked. An RMfailed exception is raised if there is a failure while closing the resource manager. A BAD_INV_ORDER standard system exception is raised if the function was called in an improper context (for example, the caller is in transaction mode). Any attempts by the remote clients or the native clients to invoke this method raises the standard system exception NO_IMPLEMENT.

Consider the following guidelines when integrating transactions into your WebLogic Enterprise CORBA client/server applications:

• Nested transactions are not permitted in the WebLogic Enterprise system.

  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.)

• The object that starts a transaction is the only entity that can end the transaction. (In a strict sense, the object can be the client application, the TP Framework, or an object managed by the server application.) An object that is invoked within the scope of a transaction may suspend and resume the transaction (and while the transaction is suspended, the object can start and end other transactions). However, you cannot end a transaction in an object unless you began the transaction there.

• WebLogic Enterprise does not support concurrent transactions. Objects can be involved with only one transaction at one time. An object is involved in a transaction for the duration of the entire transaction, and is available to be involved in a different transaction only after the current transaction is completed.

• WebLogic Enterprise does not queue requests to objects that are currently involved in a transaction. If a non-transactional client application attempts to invoke an operation on an object that is currently in a transaction, the client application receives the following error message:

  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

• For transaction-bound objects, consider doing all state handling in the com.beasys.Tobj_Servant.deactivate_object method (in Java) or Tobj_ServantBase::deactivate_object() operation (in C++). This makes it easier for the object to handle its state properly, because the outcome of the transaction is known at the time that deactivate_object() is invoked.

• For method-bound objects that have several operations, but only a few that affect the object's durable state, consider doing the following:

  • Assign the optional transaction policy.

  • Scope any write operations within a transaction, by making invocations on the TransactionCurrent object.

    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.

• Transaction rollbacks are asynchronous. Therefore, it is possible for an object to be invoked while its transactional context is still active. If you try to invoke such an object, you receive an exception.

• If an object with the always transaction policy is involved in a transaction that is started by the WebLogic Enterprise system, and not the client application, note the following:

  • If the server application marks the transaction for rollback only and the server throws a CORBA exception, the client application receives the CORBA exception.

  • If the server application marks the transaction for rollback only and the server does not throw a CORBA exception, the client application receives the OBJ_ADAPTER exception. In this case, the WebLogic Enterprise system automatically rolls back the transaction. However, the client application is completely unaware that a transaction has been scoped in the WebLogic Enterprise domain.

• If the client application initiates a transaction, and the server application marks the transaction for a rollback, one of the following occurs:

  • If the server throws a CORBA exception, the client application receives a CORBA exception.

  • If the server does not throw a CORBA exception, the client application receives the TRANSACTION_ROLLEDBACK exception.

The WebLogic Enterprise EJB container provides a Transaction Service that supports the two types of transactions in WebLogic Enterprise EJB applications:

• Container-managed transactions. In container-managed transactions, the WebLogic Enterprise EJB container manages the transaction demarcation. Transaction attributes in the EJB deployment descriptor determine how the WebLogic Enterprise EJB container handles transactions with each method invocation.

• Bean-managed transactions. In bean-managed transactions, the EJB manages the transaction demarcation. The EJB 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 EJB applications, see Transactions in WebLogic Enterprise EJB Applications, and Transactions Sample EJB Code.

WebLogic Enterprise provides a Transaction Service that supports transactions in WebLogic Enterprise 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 WebLogic Enterprise RMI Applications, and Transactions Sample RMI Code.

This topic includes the following sections:

• UserTransaction Methods

• Exceptions Thrown by UserTransaction Methods

WebLogic Enterprise provides thee javax.transaction package, from Sun Microsystems, Inc., 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 the Java Transaction API (JTA) Specification (version1.0.1) published by Sun Microsystems, Inc. For a detailed description of the javax.transaction interface, see the package description in the WebLogic Enterprise Javadoc.

Table 2-4 describes the methods in the UserTransaction object.

Table 2-4 Methods in the UserTransaction Object

Method Name	Description
begin	Starts a transaction on the current thread.
commit	Commits the transaction associated with the current thread.
getStatus	Returns the transaction status, or STATUS_NO_TRANSACTION if no transaction is associated with the current thread. One of the following values: STATUS_ACTIVE STATUS_COMMITTED STATUS_COMMITTING STATUS_MARKED_ROLLBACK STATUS_NO_TRANSACTION STATUS_PREPARED STATUS_PREPARING STATUS_ROLLEDBACK STATUS_ROLLING_BACK STATUS_UNKNOWN
rollback	Rolls back the transaction associated with the current thread.
setRollbackOnly	Marks the transaction associated with the current thread so that the only possible outcome of the transaction is to roll it back.
setTransactionTimeout	Specifies the timeout value for the transactions started by the current thread with the begin method. If an application has not called the begin method, then the Transaction Service uses a default value for the transaction timeout.

Table 2-5 describes exceptions thrown by methods of the UserTransaction object.

Table 2-5 Exceptions Thrown by UserTransaction Methods

Exception	Description
HeuristicMixedException	Thrown to indicate that a heuristic decision was made and that some relevant updates have been committed while others have been rolled back.
HeuristicRollbackException	Thrown to indicate that a heuristic decision was made and that some relevant updates have been rolled back.
NotSupportedException	Thrown when the requested operation is not supported (such as a nested transaction).
RollbackException	Thrown when the transaction has been marked for rollback only or the transaction has been rolled back instead of committed.
IllegalStateException	Thrown if the current thread is not associated with a transaction.
SecurityException	Thrown to indicate that the thread is not allowed to commit the transaction.
SystemException	Thrown by the transaction manager to indicate that it has encountered an unexpected error condition that prevents future transaction services from proceeding.