Enterprise beans—managing transactions

Clients can begin, commit, and roll back ACID transactions1 using an implementation of the Java™ Transaction Service (JTS) or the CORBA Object Transaction Service (OTS). These transactions are analogous to CICS® distributed units of work. We use the term OTS transaction to differentiate these transactions from CICS transaction definitions (the ones with 4-character transaction identifiers) and CICS transaction instances (which are sometimes loosely called “tasks”).

When a client calls an enterprise bean in the scope of an OTS transaction, information about the transaction flows to the EJB server in an IIOP “service context”, which is like an extra (hidden) parameter on the method request. The EJB server uses this information if it needs to participate in the transaction. Whether the method of an enterprise bean needs to run under a client's OTS transaction (if there is one) is determined by the setting of the transaction attribute specified in the bean's deployment descriptor. The method may run under the client's OTS transaction, under a separate OTS transaction which is created for the duration of the method, or under no OTS transaction.

Entity beans must use container–managed OTS transactions. All transaction functions are performed implicitly by the EJB container and server. There are no transaction demarcation statements within the bean code.

Session beans can use either container-managed OTS transactions or bean–managed OTS transactions. A session bean that uses bean–managed transactions uses methods of the javax.transaction.UserTransaction interface to demarcate transactions. A stateful session bean that manages its own transactions can begin an OTS transaction in one method and commit or roll it back in a subsequent method. A stateless session bean that manages its own transactions and begins an OTS transaction must commit (or roll back) the transaction in the same method.

At runtime, the EJB container implements transaction services according to the setting of the transaction attribute specified in the bean's deployment descriptor. The possible settings of the transaction attribute are:

Mandatory
Indicates that the bean must always execute within the context of the caller's OTS transaction. If the caller does not have a transaction when it calls the bean, the container throws a javax.transaction.TransactionRequiredException exception and the request fails.
Never
Indicates that the bean must not be invoked within the context of an OTS transaction. If a caller has an OTS transaction when it calls the bean, the container throws a java.rmi.RemoteException exception and the request fails.
NotSupported
Indicates that the bean cannot execute within the context of an OTS transaction. If a caller has an OTS transaction when it calls the bean, the container suspends the transaction for the duration of the method call. It resumes the suspended transaction when the method has completed. The suspended transaction context of the client is not passed to resource managers or enterprise bean objects that are invoked from the method.
Required
Indicates that the bean must execute within the context of an OTS transaction. If a caller has an OTS transaction when it calls the bean, the method participates in the caller's transaction. If the caller does not have an OTS transaction, the container starts a new OTS transaction for the method.
RequiresNew
Indicates that the bean must execute within the context of a new OTS transaction. The container always starts a new OTS transaction for the method. If the caller has an OTS transaction when it calls the bean, the container suspends the caller's transaction for the duration of the method call. The suspended transaction context of the client is not passed to resource managers or enterprise bean objects that are invoked from the method.
Supports
Indicates that the bean can run with or without a transaction context. If a caller has an OTS transaction when it calls the bean, the method participates in the caller's transaction. If the caller does not have an OTS transaction, the method runs without one.
Note: Enterprise bean methods always execute in a CICS task, under a CICS unit of work. Even if an enterprise bean method executes under no OTS transaction, any updates that the method makes to recoverable resources are committed only at normal termination of the CICS task, and backed out if there is a need to roll back.

The setting of a method's transaction attribute determines whether or not the CICS task under which the method executes makes its unit of work part of a wider, distributed OTS transaction.

A single CICS task cannot contain more than one enterprise bean, because CICS treats an execution of an enterprise bean method as the start of a new task. You can create an application that includes more than one enterprise bean, but the application will not operate as a single CICS task.

1 Transactions possessing atomicity, consistency, isolation, and durability. Jim Gray and Andreas Reuter, Transaction Processing: Concepts and Techniques, 1993.