Release 8.1.5
A64683-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Enterprise JavaBeans and CORBA Developer's Guide Release 8.1.5 A64683-01 |
|
A transaction is a unit of work, usually associated with a database management system. Transactions are described in terms of the so-called ACID properties. A transaction is:
Most of the transactional features that are part of the Oracle8i database server are available to the CORBA or EJB distributed application developer.
Oracle8i JServer supports two transaction APIs for use in CORBA and EJB applications:
The JTS is a Java binding to the OMG Object Transaction Service (OTS). It is used for client-side demarcated transactions, and for transaction management in CORBA server objects.
The UserTransaction interface is used in EJBs, where the bean is running using the transaction attribute TX_BEAN_MANAGED.
The implementations of JTS that is supplied for this Oracle8i release is intended mostly to support client-side transaction demarcation. As such it has some limitations that you should be aware of when designing your application.
This implementation of JTS does not manage distributed transactions. Transaction control distributed among multiple database servers, with support for the required two-phase commit protocol, will be available in an upcoming release of Oracle8i JServer.
The JTS transaction API supplied with Oracle8i JServer manages only one resource: an Oracle8i database session. A transaction cannot span multiple servers or multiple database sessions in a single service.
Transaction contexts are never propagated outside a server. If a server object calls out to another server, the transaction context is not carried along.
However, a transaction can involve one or many objects. The transaction can encompass one or many methods of these objects. The scope of a transaction is defined by a transaction context that is shared by the participating objects.
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 SubtransactionsUnavailable exception.
Methods of the JST that support transaction timeout, such as setTimeout(), do not work in this release. You can invoke them from your code, and no exception is thrown, but they have no effect.
The transaction services supplied with this release do not interoperate with other OTS implementations.
A transaction is said to be demarcated. This simply means that it has a definite beginning and definite end 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.
In a distributed object application, transactions are often described as client-side demarcated (or sometimes just client demarcated), or server-side demarcated (equivalently server demarcated).
In client-side demarcation, a transactional client explicitly encloses one or more method invocations on a server object with demarcation methods that begin and end transactions. The begin and end demarcaters are method calls on the client-side transaction service. See "Client-Side Demarcation" for specific examples.
Server-side transaction demarcation implies that the server-side object begins and either commits or rolls back a transaction. Note that a transaction can span several objects, any one of which can suspend, resume, or end the transaction.
The transaction context is a pseudo-object that is passed to the server object from the client, or from one server object to another, in the case where one server object is invoking methods on another, and hence acting as its client. The transaction context carries the state of the transaction.
After a client-side transaction service is initialized, and a begin transaction method is invoked, the transaction service implicitly creates a transaction context, and assigns a transaction ID number to the context. The client transaction service then propagates the transaction context to each participant in the transaction, that is, to each object that the client calls.
Propagation of the transaction context on each method invocation is normally transparent to the client program. The transaction context is maintained by the transaction service for each client. Transaction contexts are propagated transparently from the transaction initiator to the server object. On the client side, an interceptor is engaged to submit the transaction context on any method call to a server object. A server-side interceptor extracts the transaction context information, and makes it available to the server object.
As stated in "Limitations", a transaction context cannot span multiple sessions. Each new session connection requires a new transaction context.
