Oracle8i Enterprise JavaBeans Developer's Guide and Reference Release 3 (8.1.7) Part Number A83725-01 |
|
Transactions manage changes to multiple databases within a single application as a unit of work. That is, if you have an application that manages data within one or more databases, you can ensure that all changes in all databases are committed at the same time if they are managed within a transaction.
Transactions are described in terms of ACID properties, which are as follows:
The JTA implementation, specified by Sun Microsystems, relies heavily on the JDBC 2.0 specification and XA architecture. The result is a complex requirement on applications in order to ensure that the transaction is managed completely across all databases. Sun Microsystems's specifies Java Transaction API (JTA) 1.0.1 and JDBC 2.0 on http://www.javasoft.com
.
You should be aware of the following when using JTA within the Oracle8i environment:
Whenever your application connected to a database using JDBC or a SQL server, you were creating a transaction. However, the transaction involved only the single database and all updates made to the database were committed at the end of these changes. This is referred to as a local transaction.
A global transaction involves a complicated set of management objects--objects that track all of the objects and databases involved in the transaction. These global transaction objects--TransactionManager
and Transaction
--track all objects and resources involved in the global transaction. At the end of the transaction, the TransactionManager
and Transaction
objects ensure that all database changes are atomically committed at the same time.
A transaction is said to be demarcated, which means that each transaction has a definite start and stop point. For example, in an interactive tool such as SQL*Plus, each SQL DML statement implicitly begins a new transaction, if it is not already part of a transaction. A transaction ends when a SQL COMMIT or ROLLBACK statement is issued.
The important designation for a transaction depends on the originator of the transaction and whether explicitly or implicitly demarcated:
begin
or commit
methods. Explicit demarcation is discussed further in both "JTA Client-Side Demarcation" and "JTA Server-Side Demarcation".
Enterprise JavaBeans can specify whether the bean demarcates and manages any transactions within itself or whether the container should demarcate and manage the transaction.
The bean specifies itself as container-managed transactional; it does not have any transactional implementation within its methods. All transactional logic is executed by the container based on the transactional attribute specified in the EJB deployment descriptor. See the following for more information:
If the bean specifies itself as bean-managed transactional, it has the following responsibility:
When you begin a transaction within either a client or a server instance, JTA denotes the originator in the transaction manager. As the transaction involves more objects and resources, the transaction manager tracks all of these objects and resources in the transaction and manages the transaction for these entities.
When an object calls another object, in order for the invoked object to be included in the transaction, JTA propagates the transaction context to the invoked object. Propagation of the transaction context is necessary for including the invoked object into the global transaction.
As shown in Figure 7-1, if the client begins a global transaction, calls a server object in the database, the transaction context is propagated to the server object. If the server object supports transactions, this object is attached to the transaction manager as involved in the global transaction. If this server object invokes another server object, within the same or a remote database, the transaction context is propagated to this object as well. This ensures that all objects that are supposed to be involved in the global transaction are tracked by the transaction manager.
The definition of the transaction attribute within the EJB deployment descriptor for container-managed transactional beans determines whether the global transaction context is propagated to the server object. The following table lists each transaction attribute and the behavior that occurs for each server object type and for any resources.
Each resource, including databases, that you want managed in the global transaction must be enlisted. The Oracle8i JTA implementation automatically enlists all databases if you open a JDBC connection to the database within the context of a global transaction. The Oracle8i JDBC Developer's Guide contains more information on how to open a JDBC connection to a database within a transaction.
JTA automatically enlists a database resource when one of the following occurs:
The following JDBC methods are used within a local transaction for accessing the local database. In order to ensure that the statements are included within a global transaction, execute these methods and subsequent SQL statements after the global transaction has started.
An example for each of these methods of automatic enlistment are detailed in "Enlisting Resources on the Server-side".
An object--client or server object--can only enlist a database within the global transaction through JDBC 2.0 methods within the DataSource
object. The getConnection
method must be invoked after the begin
method of the UserTransaction
object.
If your transaction involves more than one database, you must specify an Oracle8i database as the two-phase commit engine. See "Configuring Two-Phase Commit Engine" for more information.
One of the primary advantages for a global transaction is the number of objects and database resources managed as a single unit within the transaction. If your global transaction involves more than one database resource, you must specify a two-phase commit engine, which is an Oracle8i database designated to manage the changes to all databases within the transaction. The two-phase commit engine is responsible for ensuring that when the transaction ends, all changes to all databases are either totally committed or fully rolled back.
On the other hand, if your global transaction has multiple server objects, but only a single database resource, you do not need to specify a two-phase commit engine. The two-phase commit engine is required only to synchronize the changes for multiple databases. If you have only a single database, single-phase commit can be performed by the transaction manager.
Note: Your two-phase commit engine can be any Oracle8i database. It can be the database where your server object exists, or even a database that is not involved in the transaction at all. See "Configuring Two-Phase Commit Engine" for a full explanation of the two-phase commit engine setup. |
Figure 7-2 shows three databases enlisted in a global transaction and another database that is designated as the two-phase commit engine. All databases, including the local database, are automatically enlisted when a JDBC connection is opened after the global transaction starts. See "Enlisting Resources" for more information on database enlistment.
When the global transaction ends, the two-phase commit engine ensures that all changes made to the databases A, B, and the local are committed or rolled back simultaneously.
The following sections summarize the details for demarcating the transaction and enlisting the database in the transaction. These details are explained and demonstrated in the rest of the chapter. However, these tables provide a reference point for you.
Container-Managed Transaction | Bean-Managed Transaction | ||
---|---|---|---|
Single-Phase Commit |
Deployment Descriptor |
|
|
Binding |
|||
Runtime |
|
||
Two-Phase Commit |
Deployment Descriptor |
In addition to the single-phase requirements, you must also add the JNDI bound name for the |
Same requirements as the container-managed transaction. |
Binding |
|
||
Runtime |
|
The following are the portions of the JTA specification that Oracle8i does not support.
Nested transactions are not supported in this release. If you attempt to begin a new transaction before committing or rolling back any existing transaction, the transaction service throws a NotSupportedException
exception.
The transaction services supplied with this release do not interoperate with other JTA implementations.
|
Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|