Using CORBA Transactions

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Transaction Service

This topic includes the following sections:

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

Notes: The Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported. All Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB text references, associated code samples, should only be used to help implement/run third party Java ORB libraries, and for programmer reference only.
Note: Technical support for third party CORBA Java ORBs should be provided by their respective vendors. Oracle Tuxedo does not provide any technical support or documentation for third party CORBA Java ORBs.

 


About the Transaction Service

Oracle 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. Oracle 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 Oracle 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 Oracle 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 Oracle 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 Oracle provided resource managers and/or XA compliant resource managers can participate in the coordination of a transaction. Further, the Oracle 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, Oracle 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. Oracle 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

Oracle 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

Oracle Tuxedo CORBA implements the flat transaction model. Nested transactions are not supported.

Interoperability Between CORBA Remote Clients and the Oracle Tuxedo Domain

Oracle Tuxedo CORBA supports remote clients invoking methods on server objects in different Oracle Tuxedo domains in the same transaction.

Remote CORBA clients with multiple connections to the same Oracle Tuxedo domain may make invocations to server objects on these separate connections within the same transaction.

Intradomain and Interdomain Interoperability

Oracle Tuxedo CORBA supports native clients invoking methods on server objects in the Oracle Tuxedo domain. In addition, Oracle Tuxedo supports server objects invoking methods on other objects in the same or in different processes within the same Oracle Tuxedo domain.

In Oracle 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 Oracle Tuxedo Domains Component .

Network Interoperability

A client application can have only one active Bootstrap object and TransactionCurrent object within a single domain. Oracle Tuxedo CORBA does not support exporting or importing transactions to or from remote Oracle 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 Oracle Tuxedo system provides management tools for keeping the application running when failures occur. Because Oracle Tuxedo CORBA is built upon the Oracle Tuxedo transaction management system, it inherits the Oracle Tuxedo capabilities for keeping applications running.

General Constraints

The following constraints apply to the Transaction Service:

 


Transaction Service in CORBA Applications

This topic includes the following sections:

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

  1. Create a Bootstrap object. For more information about creating a Bootstrap object, see the “CORBA Bootstrapping Programming Reference” in the CORBA 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 Programming Reference .
  3. If an application requires only the Transaction Service APIs, it should issue a CosTransactionsCurrent::_narrow() (in C++) on the object pointer returned from step 2 above.
  4. If an application requires the Transaction Service APIs with the extensions, it should issue a Tobj::TransactionCurrent::_narrow() (in C++) on the object pointer returned from step 2 above.

Getting Initial References to the TransactionFactory Object Using INS

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

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

Listing 2-4 Current Interface IDL
// 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.

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.

Table 2-2 Transaction Methods in the Current Object 
Method
Description
begin
Creates a new transaction. The transaction context of the client application is modified so that the thread is associated with the new transaction. If the client application is currently associated with a transaction, the SubtransactionsUnavailable exception is raised. If the client application 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 application, 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 application, 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 application, the NoTransaction exception is raised. Otherwise, the transaction associated with the client application 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 application, the StatusNoTransaction value is returned. Otherwise, this method returns the status of the transaction associated with the client application.
get_transaction_name
If there is no transaction associated with the client application, 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 timeout 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 Oracle Tuxedo 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 application. This object may be given to the resume method to reestablish this context.
suspend
If the client application 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 application 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 application. The same client can subsequently give this object to the resume method to reestablish this context. In addition, the client application becomes associated with no transaction.

Note: As defined in The Common Object Request Broker: Architecture and Specification, Revision 2.4, 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 application 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 application 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 application becomes associated with no transaction. If the parameter is valid in the current execution environment, the client application 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-5 shows the Control interface, which is defined in the CosTransactions module.

Listing 2-5 Control Interface
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.

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

Table 2-3 describes the Terminator interface methods.

Table 2-3 Termination Interface Methods
Method
Description
commit
If the transaction has not been marked rollback only, and all of the participants in the transaction agree to commit, the transaction is committed and the operation terminates normally. Otherwise, the transaction is rolled back (as described below for the rollback method) and the TRANSACTION_ROLLEDBACK standard exception is raised.
If the report_heuristics parameter is true, the Transaction Service will report inconsistent or possibly inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions. A Transaction Service implementation may optionally use the CORBA Notification Service to report heuristic decisions.
The commit operation may roll back the transaction if there are subtransactions of the transaction that have not themselves been committed or rolled back or if there are existing or potential activities associated with the transaction that have not completed. The nature and extent of such error checking is implementation-dependent. When a top-level transaction is committed, all changes to recoverable objects made in the scope of this transaction are made permanent and visible to other transactions or clients. When a subtransaction is committed, the changes are made visible to other related transactions as appropriate to the degree of isolation enforced by the resources.
rollback
The transaction is rolled back.
When a transaction is rolled back, all changes to recoverable objects made in the scope of this transaction (including changes made by descendant transactions) are rolled back. All resources locked by the transaction are made available to other transactions as appropriate to the degree of isolation enforced by the resources.

TransactionalObject Interface

In Oracle 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
interface TransactionalObject {
};
// This information was taken from the OMG Transaction Service
// Specification
, Version 1.1, May 2000. Used with permission
// of the OMG.

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

Table 2-4 describes the TransactionFactory interface methods.

Table 2-4 TransactionFactory Interface Methods
Method
Description
create
A new top-level transaction is created and a Control object is returned. The Control object can be used to manage or to control participation in the new transaction. An implementation of the Transaction Service may restrict the ability for the Control object to be transmitted to or used in other execution environments; at a minimum, it can be used by the client application.
If the parameter has a nonzero value n, then the new transaction will be subject to being rolled back if it does not complete before n seconds have elapsed. If the parameter is zero, then no application specified timeout is established.
recreate
Not supported.

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 {
      void open_xa_rm()
             raises(RMfailed);
      void close_xa_rm()
             raises(Rmfailed);
}

Table 2-5 describes APIs that are specific to the resource manager. For more information about these APIs, see the CORBA Programming Reference .

Table 2-5 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.

Notes on Using Transactions in Oracle Tuxedo CORBA Applications

Consider the following guidelines when integrating transactions into your Oracle Tuxedo CORBA client/server applications:

 


UserTransaction API

This topic includes the following sections:

UserTransaction Methods

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

Table 2-6 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.

Exceptions Thrown by UserTransaction Methods

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

Table 2-7 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.


  Back to Top       Previous  Next