Programming Transactions in Session Beans

The WebLogic EJB container provides both Container-Managed and Bean-Managed Transaction support for session beans, which is specified by the <transaction-type> element in the bean's ejb-jar.xml deployment descriptor. This tag can have the value Bean or Container . Bean implies that the EJB will perform all the transaction management, and Container means that the bean requests the WebLogic EJB container to perform transaction management. The following sections discuss both transaction management techniques.

For a detailed discussion on the Java Transaction API, see Chapter 16, "Managing Java Transactions Using JTA," p. 527 .

Container-Managed Transactions

When Container-Managed Transactions (CMT) are used, the EJB container requires additional information on how and when to start transactions. This information is also provided in the deployment descriptor in the <container-transaction> element. Six keywords define the transaction attribute (see Table 20.7). The transaction attribute can be applied on a per-bean basis or to individual methods within the bean.

Table 20.7. Transaction Attributes for Session Beans

Transaction Attribute	Description
Never	The EJB call cannot participate in a transaction. If the call is made within a transaction, RemoteException is thrown.
NotSupported	The EJB call does not participate in transactions regardless of whether a transaction has been started.
Supports	The EJB call participates in the transaction if one has been started; otherwise , it does not.
Mandatory	The EJB call must occur after a transaction has been started; otherwise, TransactionRequiredException is thrown.
Required	The EJB call participates in the transaction that the client started. If the client has not started a transaction, the EJB container starts a transaction and commits the transaction when the call completes.
RequiresNew	The EJB container always starts a new transaction before calling the EJB method. The EJB container commits the transaction when the call returns.

If no <container-transaction> element is provided in the deployment descriptor, the WebLogic EJB container defaults to Supports for all methods in the EJB. An example of the <container-transaction> element from the ejb-jar.xml file is shown in Listing 20.16.

Listing 20.16 An Example of the <container-transaction> Element from the ejb-jar.xml File

 <container-transaction>     <method>         <ejb-name>MySessionBean</ejb-name>         <method-name>*</method-name>     </method>     <trans-attribute>Required</trans-attribute> </container-transaction> 

Listing 20.16 sets the Required transaction attribute for all methods in the MySessionBean bean.

The <method> tag section can have specific method names . To support method overloading, a list of method parameters can be supplied to select a specific method signature. An example of a <container-transaction> element that specifies the Mandatory transaction attribute for the getBalance( String account ) method is shown in Listing 20.17.

Listing 20.17 An Example of <container-transaction> Specifying the Mandatory Transaction Attribute

 <container-transaction>     <method>         <ejb-name>MySessionBean</ejb-name>         <method-name>getBalance</method-name>         <method-params>java.lang.String</method-params>     </method>     <trans-attribute>Mandatory</trans-attribute> </container-transaction> 

Bean-Managed Transactions

Bean-Managed Transactions (BMT) are indicated when the <transaction-type> element in the deployment descriptor is set to Bean . The EJB must then directly call methods on the UserTransaction object. With CMT, transaction boundaries are set by the client or EJB container. With BMT, the EJB gets a reference to the UserTransaction object by calling getUserTransaction() on the SessionContext object. The SessionContext object is passed to the EJB through the setSessionContext() method. The EJB can call the begin, commit, and rollback methods on the UserTransaction object. A stateless session bean must commit or roll back every transaction before returning from the method call. A stateful session bean can keep a transaction active across multiple method calls.

Keep in mind that although the stateful session bean is caching the client's conversational state, the state is not considered transactional. Therefore, it is not automatically rolled back to some initial state when the transaction it participates in is rolled back. The bean developer needs to provide logic to accomplish this task.

Note

In CMT, implementing the SessionSynchronization interface gives a stateful session bean additional callback methods to help maintain its state in a transaction. The session bean has the capability to roll its state backward or forward, based on a transaction's success or failure.