| CONTENTS | PREV | NEXT | INDEX | J2EE BluePrints |
There are two types of transaction demarcation in enterprise beans: bean-managed
and container-managed. In container-managed transaction demarcation, six different
transaction attributes--Required, RequiresNew,
NotSupported, Supports, Mandatory, and
Never--can be associated with an enterprise bean's
method. An Application Component Provider or Assembler specifies the type of
transaction demarcation and transaction attributes for the methods of the enterprise
beans in the deployment descriptor. The use of deployment descriptors to specify
transaction elements is discussed and illustrated in "Transaction
Elements" on page 184.
This section discusses the types of transactions and the attributes of container-managed transactions and then presents guidelines for choosing among the available options.
With bean-managed transaction demarcation, an enterprise bean uses the javax.transaction.UserTransaction interface to explicitly demarcate transaction boundaries. Only session beans can choose to use bean-managed demarcation. An entity bean must always use container-managed transaction demarcation.
The following code illustrates the use of JTA interface to demarcate transactions in an enterprise bean with bean-managed transaction demarcation.
UserTransaction ut = ejbContext.getUserTransaction(); ut.begin(); // perform transactional work here ut.commit();
| Code Example 8.2 Enterprise Bean Using a JTA Transaction |
For an enterprise bean with container-managed transaction demarcation, the EJB container is responsible for managing transaction boundaries. The transaction attribute for a method determines what the EJB container needs to do in terms of transaction management. For example, if a method has a transaction attribute RequiresNew, the EJB container will begin a new JTA transaction every time this method is called and attempt to commit the transaction before the method returns. The same transaction attribute can be specified for all the methods of an enterprise bean or different attributes can be specified for each method of a bean. Refer to Section 8.7.2.1 for more information on transaction attributes.
Even in container-managed demarcation, an enterprise bean has some control over the transaction. For example, an enterprise bean can choose to roll back a transaction started by the container using the method setRollbackOnly on the SessionContext or EntityContext object.
There are several benefits of using container-managed transaction demarcation:
- The transaction behavior of an enterprise bean is specified declaratively instead of programmatically. This frees the Application Component Provider from writing transaction demarcation code in the component.
- It is less error-prone because the container handles transaction demarcation automatically.
- It is easier to compose multiple enterprise beans to perform a certain task with specific transaction behavior. An Application Assembler that understands the application can customize the transaction attributes in the deployment descriptor without code modification.
8.7.2.1 Transaction Attributes
A transaction attribute is a value associated with a method of an enterprise bean that uses container-managed transaction demarcation. In most cases, all methods of an enterprise bean will have the same transaction attribute. For optimization purposes, it is possible to have different attributes for different methods. For example, an enterprise bean may have methods that don't need to be transactional.
A transaction attribute must be specified for the methods in the remote interface of a session bean and for the methods in the remote and home interfaces of an entity bean.
If the transaction attribute is Required, the container ensures that the enterprise bean's method will always be invoked with a JTA transaction. If the calling client is associated with a JTA transaction, the enterprise bean method will be invoked in the same transaction context. However, if a client is not associated with a transaction, the container will automatically begin a new transaction and try to commit the transaction when the method completes.
If the transaction attribute is RequiresNew, the container always creates a new transaction before invoking the enterprise bean method and commits the transactions when the method returns. If the calling client is associated with a transaction context, the container suspends the association of the transaction context with the current thread before starting the new transaction. When the method and the transaction complete, the container resumes the suspended transaction.
If the transaction attribute is NotSupported, the transactional context of the calling client is not propagated to the enterprise bean. If a client calls with a transaction context, the container suspends the client's transaction association before invoking the enterprise bean's method. After the method completes, the container resumes the suspended transaction association.
It the transaction attribute is Supports, and the client is associated with a transaction context, the context is propagated to the enterprise bean method, similar to the way the container treats the Required case. If the client call is not associated with any transaction context, the container behaves similarly to the NotSupported case. The transaction context is not propagated to the enterprise bean method.
The transaction attribute Mandatory requires the container to invoke a bean's method in a client's transaction context. If the client is not associated with a transaction context when calling this method, the container throws javax.transaction.TransactionRequiredException. If the calling client has a transaction context, the case is treated as Required by the container.
The transaction attribute Never requires that the enterprise bean method not be called within a transaction context. If the client calls with a transaction context, the container throws the java.rmi.RemoteException. If the client is not associated with any transaction context, the container invokes the method without initiating a transaction.
As mentioned previously, the recommended way to manage transactions is through container-managed demarcation. Declarative transaction management provides one of the major benefits of the J2EE platform, by freeing the Application Component Provider from the burden of managing transactions. Furthermore, the transaction characteristics of an application can be changed without code modification by switching the transaction attributes. Transaction demarcation should be selected with great care, by someone who understands the application well. Bean-managed transaction demarcation is only for advanced users who want more control over the work flow.
8.7.3.1 Transaction Attributes Guidelines
Most enterprise beans perform transactional work (for example, accessing a JDBC database). The default choice for a transaction attribute should be Required. Using this attribute ensures that the methods of an enterprise bean are invoked under a JTA transaction. In addition, enterprise beans with the Required transaction attribute can be easily composed to perform work under the scope of a single JTA transaction.
The RequiresNew transaction attribute is useful when the bean method needs to commit its results unconditionally, whether or not a transaction is already in progress. An example of this requirement is a bean method that performs logging. This bean method should be invoked with RequiresNew transaction attribute so that the logging records are created even if the calling client's transaction is rolled back.
The NotSupported transaction attribute can be used when the resource manager responsible for the transaction is not supported by the J2EE product. For example, if a bean method is invoking an operation on an enterprise resource planning system that is not integrated with the J2EE server, the server has no control over that system's transactions. In this case, it is best to set the transaction attribute of the bean to be NotSupported to clearly indicate that the enterprise resource planning system is not accessed within a JTA transaction.
We do not recommend using the transaction attribute Supports. An enterprise bean with this attribute would have transactional behavior that differed depending on whether the caller is associated with a transaction context, leading to possibly a violation of the ACID rules for transactions.
The transaction attributes Mandatory and Never can be used when it is necessary to verify the transaction association of the calling client. They reduce the composability of a component by putting constraints on the calling client's transaction context.