The current connection mode restricts which operations are valid within a transaction. This mode-restriction error checking is in addition to the standard error checking on the transaction and savepoint APIs, documented in this chapter and in "Transaction Savepoints". Oracle supplies the following three packages that have classes to implement distributed transaction functionality according to the XA standard:.
An abstract class for each is in the top-level package. If you intend your XA code to run in the target Oracle database, however, you will import the oracle. If code that will run inside a target database must also access remote databases, then do not import either package--instead, you must fully qualify the names of any classes that you use from the client package to access a remote database or from the server package to access the local database.
Class names are duplicated between these packages. The following topics are covered:. The javax. The overloaded getXAConnection method returns an XA connection instance and optionally takes a user name and password as input:. An XA connection instance, as with a pooled connection instance, encapsulates a physical connection to a database.
This would be the database specified in the connection properties of the XA data source instance that produced the XA connection instance. Each XA connection instance also has the facility to produce the XA resource instance that will correspond to it for use in coordinating the distributed transaction.
An XA connection instance is an instance of a class that implements the standard javax. XAConnection interface:. As you see, the XAConnection interface extends the javax. The getConnection method returns an OracleConnection instance. A JDBC connection instance returned by an XA connection instance acts as a temporary handle to the physical connection, as opposed to encapsulating the physical connection.
The physical connection is encapsulated by the XA connection instance. Each time an XA connection instance getConnection method is called, it returns a new connection instance that exhibits the default behavior, and closes any previous connection instance that still exists and had been returned by the same XA connection instance. It is advisable to explicitly close any previous connection instance before opening a new one, however. Calling the close method of an XA connection instance closes the physical connection to the database.
This is typically performed in the middle tier. The transaction manager uses XA resource instances to coordinate all the transaction branches that constitute a distributed transaction. Each XA resource instance provides the following key functionality, typically invoked by the transaction manager:.
An XA resource instance is an instance of a class that implements the standard javax. XAResource interface:. This method is how an OracleXAResource instance is associated with a particular connection and with the transaction branch being executed in that connection.
The OracleXAResource class has several methods to coordinate a transaction branch with the distributed transaction with which it is associated. A transaction manager, receiving OracleXAResource instances from a middle-tier component such as an application server, typically invokes this functionality.
Each of these methods takes a transaction ID as input, in the form of an Xid instance, which includes a transaction branch ID component and a distributed transaction ID component. Every transaction branch has a unique transaction ID, but transaction branches belonging to the same global transaction have the same global transaction component as part of their transaction IDs. Following is a description of key XA resource functionality, the methods used, and additional input parameters.
Each of these methods throws an XA exception if an error is encountered. Start work on behalf of a transaction branch, associating the transaction branch with a distributed transaction. Note that to create an appropriate transaction ID in starting a transaction branch, the transaction manager must know which distributed transaction the transaction branch should belong to.
The mechanics of this are handled between the middle tier and transaction manager and are beyond the scope of this document. End work on behalf of the transaction branch specified by xid , disassociating the transaction branch from its distributed transaction. Prepare the changes performed in the transaction branch specified by xid. This is the first phase of a two-phase COMMIT operation, to ensure that the database is accessible and that the changes can be committed successfully.
Commit prepared changes in the transaction branch specified by xid. This is the second phase of a two-phase COMMIT and is performed only after all transaction branches have been successfully prepared.
Tells the resource manager to forget about a heuristically completed transaction branch. The transaction manager calls this method during recovery to obtain the list of transaction branches that are currently in prepared or heuristically completed states.
The flag parameter is ignored and therefore not implemented for Oracle8 i 8. There are many names for it:. This standard describes specifically how Resources with resource managers and Transactions with transactions managers aka XA coordinator are done. In the first phase of the protocol, called a commit-request phase or a voting phase, a coordinator normally the process that initiated the commit gets the approval or rejection to commit the data changes of involved processes. In the second phase a commit phase the coordinator informs the participants about the result.
According to the result, either the entire transaction is rolled back or all the subtransactions are successfully completed and the temporarly locked resources are released. During the two phases, the following messages are exchanged between the coordinator and the participants:. To eliminate this issue, we can use 3pc protocol. Commit — request phase also called voting phase : Commit phase: Disadvantages.
The XA interfaces enable the resource managers to join transactions, to perform 2PC two phase commit and to recover in-doubt transactions following a failure. The interface between the application and the resource manager allows an application to call a resource manager directly, using the resource manager's native API or native XA API depending on if the transaction needs to be managed by the transaction monitor or not.
The interface between the application and the transaction monitor TX interface , lets the application call the transaction monitor for all transaction needs like starting a transaction, ending a transaction, rollback of a transaction etc. The interface between the transaction monitor and the resource manager is the XA interface. This is the interface, which facilitates the two-phase commit protocol to achieve distributed transactions under one global transaction.
The JTA primarily consists of three parts:. A high-level application interface for an application to demarcate transaction boundaries. The UserTransaction interface encapsulates this. This encompasses the interfaces defined in the javax. A high-level transaction manager interface that allows an application server to manage transactions for a user application.
The TransactionManager, Transaction, Status and Synchronization interfaces pretty much define how the application server manages transactions. Now that we have a brief summary of what JTA and XA standards are, let us go through some use cases to demonstrate the integration of different JTA implementations using Spring, for our hypothetical java application.
To demonstrate the integration of different JTA implementations with Spring, we are going to use the following use cases:. In the process, we will see how we can declaratively apply distributed transaction semantics to simple POJO's.
Before going through the use cases, let us briefly look at the technology stack we are going to use. Spring framework has established itself as one of the most useful and productive frameworks in the Java world. Among the many benefits it provides, it also provides the necessary plumbing for running an application with any JTA implementation. This makes it unique in the sense that an application doesn't need to run in a JEE container to get the benefits of JTA transactions.
Please note that Spring doesn't provide any JTA implementation as such. The only task from the user perspective is to make sure that the JTA implementation is wired to use the Spring framework's JTA support. This is what we will be focusing on in the following sections. Spring provides both programmatic and declarative transaction management using a lightweight transaction framework.
This makes it easy for standalone java applications to include transactions JTA or non-JTA either programmatically or declaratively.
0コメント