Previous Next Contents Index


Handling Transactions with EJBs

This chapter describes the transaction support built into the Enterprise JavaBean programming model.

This chapter begins by introducing the EJB transaction model and explains the notion of container and bean managed transactions. Then it explains the semantics of all transaction attributes and use of the Java Transaction API for bean managed transactions. Finally, it discusses the restrictions on various combinations of EJB types and transaction attributes.

This chapter includes the following sections:


Understanding the Transaction Model
One of the primary advantages of using Enterprise JavaBeans (EJBs) is the support they provide for declarative transactions. In the declarative transaction model, attributes are associated with beans at deployment time and it is the container's responsibility, based on the attribute value, to demarcate and transparently propagate transactional context. The container is also responsible, in conjunction with a Transaction Manager, for ensuring that all participants in the transaction see a consistent outcome.

Declarative transactions free the programmer from explicitly demarcating transactions. They facilitate component-based applications where multiple components, potentially distributed and updating heterogeneous resources, can participate in a single transaction. The EJB specification also supports programmer-demarcated transactions using javax.transactions.UserTransaction().

It is necessary to understand the distinction between global and local transactions in order to understand the NAS support for transactions. Global transactions are managed and coordinated by a Transaction Manager and can span multiple databases and processes. The Transaction Manager typically uses the XA protocol to interact with the database backends. Local transactions, on the other hand, are native to a database and are restricted within a single process. Local transactions can work against only a single backend. Local transactions are typically demarcated using JDBC APIs.

In NAS, all transactions started by the container or by using javax.transaction.UserTransaction() are global transactions.

The EJB specification requires support for flat (as opposed to nested) transactions. In this model each transaction is decoupled from and independent of other transactions in the system. Flat transactions are by far the most prevalent model and are supported by most commercial database systems.

Note. If your application uses global transactions, your should configure and enable the corresponding NAS Resource Managers. See the Administration Guide for further details.


Specifying Transaction Attributes in an EJB
Transactional attributes can be specified on a bean-wide basis or on a per-method basis for a bean's remote interface. If attributes are specified at both levels, method-specific values take precedence over bean-wide values. These two should be mixed with care since some combinations are invalid as documented in the restrictions section.

Transactional attributes are specified as part of the bean's property file (see Specifying Transaction Requirements). The following table lists all possible values of the attributes and their associated semantics.

Transaction Management Attribute
Purpose
TX_BEAN_MANAGED
The EJB or method explicitly controls transaction boundaries using the javax.transaction.UserTransaction interface. The container does not manage transactions for this bean.
TX_MANDATORY
The EJB container invokes the EJB method using the transaction context associated with the calling client. If the client has not started a transaction when the bean is invoked, the container throws the TransactionRequired exception.
TX_NOT_SUPPORTED
The container invokes the EJB without a transaction context. If a client calls with a transaction scope, the container suspends the association of the transaction with the current thread before delegating the method call to the EJB. When the bean's work is completed, the container resumes the transaction.
TX_REQUIRED
The container invokes the EJB using the client's transactional context, unless the client does not have one. If the client does not have a transaction in progress, the container automatically starts a transaction before delegating the method call to the bean. The container attempts to commit the transaction when the method call on the bean is completed, unless the transaction was marked for rollback or an exception was raised.
TX_REQUIRES_NEW
The EJB requires that the container start a new transaction when a method is invoked. The container attempts to commit the transaction when the bean's method call completes. When a client calls into a bean with this attribute, the container suspends the client's transaction before starting the bean's new transaction. Upon completing the bean's transaction, the container resumes the client's suspended transaction.
TX_SUPPORTS
The EJB mirrors the client's transaction scope. If the client has a transaction context, the EJB is invoked in that context. If not, the EJB is invoked without a transaction context.


Using Bean Managed Transactions
While it is preferable to use container-managed transactions, you may find that your application requirements necessitate the use of bean-managed transactions. To manage transactions programmatically, set the bean's transactional attribute to TX_BEAN_MANAGED. The application can use javax.transaction.UserTransaction(), which is made available by the container via EJBContext.

The following code snippet illustrates the usage pattern. 

import javax.transaction.UserTransaction; 
... 
EJBContext ejbContext = ...; 
... 
UserTransaction tx = ejbContext.getUserTransaction(); 
tx.begin(); 
... // do work 
tx.commit();
EJBs with attributes other than TX_BEAN_MANAGED are forbidden from using javax.transaction.UserTransaction(). For more information, see the Java specification for this interface at the following URL:

http://java.sun.com/products/ejb/javadoc-1.1/javax/ejb/EJBContext.html


Restrictions on Transaction Attributes
NAS prohibits certain combination of bean types and transaction attributes. The following combinations are not permitted.


Setting Isolation Levels
NAS does not support declarative isolation levels. You should set your desired isolation level programmatically using the setTransactionIsolation() method in the JDBC API. For more information about isolation levels, see Specifying Transaction Isolation Level.

Specifying Transaction Requirements.Specifying Transaction Requirements.Specifying Transaction Isolation Level.

 

© Copyright 1999 Netscape Communications Corp.