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
MyEJBean bean is assigned the transaction
Mandatory; all other methods of
MyEJBean bean are assigned the attribute
Required. All the methods of the enterprise bean
MyOtherEJBean are assigned the attribute
<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
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
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
Requiredsince it ensures that the methods of an enterprise bean are invoked under a JTA transaction. In addition, enterprise beans with the
Requiredtransaction 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,
RequiresNewtransaction attribute is recommended. An example of this requirement is a bean method that performs logging. This bean method should be invoked with
RequiresNewtransaction attribute so that the logging records are created even if the calling client's transaction is rolled back.
NotSupportedtransaction 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
NotSupportedto clearly indicate that the enterprise resource planning system is not accessed within a JTA transaction.
- Using the transaction attribute
Supportsisn'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
Nevercan 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.