J2EE Transaction Frameworks, Part 3
Pages: 1, 2, 3, 4

Format 1 Deployment Descriptor

This format is used to specify a default value of the transaction attribute for all the methods. There must be at most one container-transaction element for a given enterprise bean.

<method>
<ejb-name>MyEjb</ejb-name>
<method-name>myMethod</method-name>
</method>

Format 2 Deployment Descriptor

This format is used to refer to a specified method of the remote or home interface of the specified enterprise bean. If there are multiple methods with the same overloaded name, this format refers to all the methods with the same name. There must be at most one container-transaction element for a given method name. If there is also a container-transaction element that uses format-1 element for the same bean, the value specified by the format-2 element takes precedence

<method>
<ejb-name>MyEjb</ejb-name>
<method-name>myMethod</method-name>
<method-params>
<method-param>myParameter1</method-param>
...
<method-param>myParameterN</method-param>
</method-params>
</method>

Format 3 Deployment Descriptor

This format is used to refer to a single method within a set of methods with an overloaded name. The method must be defined in the remote or home interface of the specified enterprise bean. If there is also a container-transaction element that uses the format-2 element for the method name, or the format-1 element for the bean, the value specified by the format-3 element takes precedence. The optional method-intf element can be used to differentiate between methods with the same name and signature that are defined in both the remote and home interfaces.

The following is an example of the specification of the transaction attributes in the deployment descriptor. The myMethod method of MyEJBean bean is assigned the transaction attribute Mandatory; all other methods of MyEJBean bean are assigned the attribute Required. All the methods of the enterprise bean MyOtherEJBean are assigned the attribute RequiresNew.

<ejb-jar>
...
<assembly-descriptor>
...
<container-transaction>
<method>
<ejb-name>MyEJBean</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>MyEJBean</ejb-name>
<method-name>myMethod</method-name>
</method>
<trans-attribute>Mandatory</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>MyOtherEJBean</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>RequiresNew</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>

Local transaction optimization:

The container may use a local transaction optimization for enterprise beans whose deployment descriptor indicates that connections to a resource manager are shareable. The container manages the use of the local transaction optimization transparent to the application.

The container may use the optimization for transactions initiated by the container for a bean with container-managed transaction demarcation and for transactions initiated by a bean with bean-managed transaction demarcation with the UserTransaction interface. The container cannot apply the optimization for a bean with container-managed transaction demarcation if the client invokes the bean with a transaction context that is imported by the container and the bean method has the Required or Mandatory transaction attribute.

Guidelines in JTA/XA

The recommended way to manage transactions in J2EE is through container-managed specification. One of the major benefits of the J2EE platform is that it frees the designer and developer of application components from the burden of managing transactions by means of declarative transaction specification. Moreover, the transaction characteristics of an application can be changed with absolutely no modification of the developed code by just changing the transaction attributes in the deployment descriptors. It also results in a separation of roles. Transaction attributes are selected by someone who understands the application well, rather than someone who may just know one part of it. Bean-managed transaction specification is recommended in applications where more control over workflow is needed.

Choosing transaction attributes:

Almost all enterprise beans perform transactional work by accessing some form of resource like an EIS or an RDBMS via JDBC. The recommended use of different transaction attributes for enterprise beans taking part in transactional work is given below.

• The default recommended choice for a transaction attribute is Required since it 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.
• If an enterprise bean method needs to commit its results unconditionally, whether or not a transaction is already in progress, the RequiresNew transaction attribute is recommended. 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 being accessed for a transaction cannot be part of a JTA transaction. This is the case 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.
• Using the transaction attribute Supports isn't recommended. An enterprise bean with this attribute would have transactional behavior that differed depending on whether the caller is associated with a transaction context, possibly leading to 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.

Pages: 1, 2, 3, 4

Next Page