| Manipulate transactional behavior of EJBs using deployment descriptors | ||
|---|---|---|
| Prev | Chapter 5. EJB transactions | Next |
In the J2EE environment, the most logical place to perform transactions is inside of an Enterprise JavaBeans (EJB ) technology component (also called an enterprise bean). There are two approaches you can take if you use enterprise beans to perform transactions. The first approach allows the EJB container to manage the transaction boundaries. This puts less of a burden on the programmer. This approach is called container-managed transactions (CMT). The second approach allows the programmer more freedom by explicitly defining the boundaries of transactions in the enterprise bean code. This approach is called bean-managed transactions (BMT).
Container-managed transactions can be used with any type of enterprise bean (session bean, entity bean, or message-driven bean). With container-managed transactions, the EJB container sets the boundaries of the transaction. This is typically done by marking one or more methods in the bean as individual transactions. The container sets the transaction boundary just before the beginning of the method, and sets the end boundary just before the method exits. However, with container-managed transactions, each method can be only one transaction - multiple transactions are not allowed. When deploying a bean, you specify which of the bean's methods are associated with transactions. You do this by setting the transaction attributes.
Transaction attributes control the scope of a transaction when one enterprise bean method calls another enterprise bean method. The JTA specification states that an enterprise bean method can be marked with one of six different transaction attributes in the EJB deployment descriptor. The transaction attribute indicates how the EJB container should treat the method called by the client enterprise bean when transactions are involved.
Transaction attributes appear in the EJB deployment descriptor as follows:
<ejb-jar> .... <assembly-descriptor> <container-transaction> <method> <ejb-name>Cabin</ejb-name> <method-intf>Local</method-intf> <method-name>*</method-name> </method> <method> <ejb-name>Cabin</ejb-name> <method-intf>LocalHome</method-intf> <method-name>create</method-name> <method-params> <method-param>java.lang.Integer</method-param> </method-params> </method> <trans-attribute>Required</trans-attribute> </container-transaction> </assembly-descriptor> </ejb-jar>
Here is what the EJB 2.0 Specification says about each of the six transaction attributes:
Required - If the client is running within a transaction and invokes the enterprise bean's method, the method executes within the client's transaction. If the client is not associated with a transaction, the container starts a new transaction before running the method. Most container-managed transactions use Required.
RequiresNew - If the client is running within a transaction and invokes the enterprise bean's method, the container suspends the client's transaction, starts a new transaction, delegates the call to the method, and finally resumes the client's transaction after the method completes. If the client is not associated with a transaction, the container starts a new transaction before running the method.
Mandatory - If the client is running within a transaction and invokes the enterprise bean's method, the method executes within the client's transaction. If the client is not associated with a transaction, the container throws the TransactionRequiredException. Use the Mandatory attribute if the enterprise bean's method must use the transaction of the client.
NotSupported - If the client is running within a transaction and invokes the enterprise bean's method, the container suspends the client's transaction before invoking the method. After the method has completed, the container resumes the client's transaction. If the client is not associated with a transaction, the container does not start a new transaction before running the method. Use the NotSupported attribute for methods that don't need transactions. Because transactions involve overhead, this attribute may improve performance.
Supports - If the client is running within a transaction and invokes the enterprise bean's method, the method executes within the client's transaction. If the client is not associated with a transaction, the container does not start a new transaction before running the method. Because the transactional behavior of the method may vary, you should use the Supports attribute with caution.
Never - If the client is running within a transaction and invokes the enterprise bean's method, the container throws a RemoteException. If the client is not associated with a transaction, the container does not start a new transaction before running the method.
There are two ways to roll back a container-managed transaction. If a system exception is thrown, the container automatically rolls back the transaction. You can also roll back a transaction by invoking the setRollbackOnly() method of the EJBContext interface. This instructs the container to roll back the transaction. If an enterprise bean throws an application exception, the rollback is not automatic, but the rollback can be initiated by a call to setRollbackOnly(). NOTE, that you cannot invoke some JTA methods while using container-managed transactions. That's because these methods are reserved for use with bean-managed transactions. These methods are:
The getUserTransaction() method of javax.ejb.EJBContext
Any method of javax.transaction.UserTransaction
Adding container transactions
Some container transaction settings are not available for all enterprise beans. Also, some methods are not available for particular transaction settings and beans. These rules have been implemented in the Add Container Transaction wizard based on the EJB 1.1 and EJB 2.0 specifications.
To add a container transaction to an enterprise bean:
In the J2EE Hierarchy view, right-click the desired EJB module (titan).
Select Open With > Deployment Descriptor Editor from the pop-up menu.
On the Assembly Descriptor page of the editor, scroll to the Container transactions section. Click Add. The Add Container Transaction wizard appears.
Select one or more enterprise beans from the list of beans found.
Select a container transaction type from the following choices:
NotSupported - Directs the container to invoke bean methods without a transaction context. If a client calls a bean method from within a transaction context, the container suspends the association between the transaction and the current thread before invoking the method on the enterprise bean instance. The container then resumes the suspended association when the method invocation returns. The suspended transaction context is not passed to any enterprise bean objects or resources that are used by this bean method.
Supports - Directs the container to invoke the bean method within a transaction context if the client calls the bean method within a transaction. If the client calls the bean method without a transaction context, the container calls the bean method without a transaction context. The transaction context is passed to any enterprise bean objects or resources that are used by this bean method.
Required - Directs the container to invoke the bean method within a transaction context. If a client calls a bean method from within a transaction context, the container calls the bean method within the client transaction context. If a client calls a bean method outside a transaction context, the container creates a new transaction context and calls the bean method from within that context. The transaction context is passed to any enterprise bean objects or resources that are used by this bean method.
RequiresNew - Directs the container to always invoke the bean method within a new transaction context, regardless of whether the client calls the method within or outside a transaction context. The transaction context is passed to any enterprise bean objects or resources that are used by this bean method.
Mandatory - Directs the container to always invoke the bean method within the transaction context associated with the client. If the client attempts to invoke the bean method without a transaction context, the container throws the javax.jts.TransactiononRequiredException exception to the client. The transaction context is passed to any EJB object or resource accessed by an enterprise bean method. EJB clients that access these entity beans must do so within an existing transaction. For other enterprise beans, the enterprise bean or bean method must implement the Bean Managed value or use the Required or Requires New value. For non-enterprise bean EJB clients, the client must invoke a transaction by using the javax.transaction.UserTransaction interface.
Never - Directs the container to invoke bean methods without a transaction context. If the client calls a bean method from within a transaction context, the container throws the java.rmi.RemoteException exception. If the client calls a bean method from outside a transaction context, the container behaves in the same way as if the Not Supported transaction attribute was set. The client must call the method without a transaction context
Select one or more methods elements from the list.
Click Finish. 0
Visit http://java.boot.by for the updates.
| Prev | Up | Next |
| Use JTA to control transaction demarcation | Home | Chapter 6. Assemble enterprise applications and deploy them in IBM WebSphere Application Server |