Sun Microsystems Inc

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

<ejb-jar>

...

<assembly-descriptor>

...

<container-transaction> <method>

<ejb-name>EmployeeRecord</ejb-name> <method-name>*</method-name>

</method> <trans-attribute>Required</trans-attribute>

</container-transaction>

<container-transaction> <method>

<ejb-name>EmployeeRecord</ejb-name> <method-name>updatePhoneNumber</method-name>

</method> <trans-attribute>Mandatory</trans-attribute>

</container-transaction>

<container-transaction> <method>

<ejb-name>AardvarkPayroll</ejb-name> <method-name>*</method-name>

</method> <trans-attribute>RequiresNew</trans-attribute>

</container-transaction> </assembly-descriptor>

</ejb-jar>

16.6 Deployer’s responsibilities

The Deployer is responsible for ensuring that the methods of the deployed enterprise beans with con- tainer-managed transaction demarcation have been assigned a transaction attribute. If the transaction attributes have not been assigned previously by the Assembler, they must be assigned by the Deployer.

16.7 Container Provider responsibilities

This section defines the responsibilities of the Container Provider.

Sun Microsystems Inc.

Every client method invocation on a session or entity bean object via the bean’s remote and home interface and every invocation of the onMessage method on a message-driven bean is interposed by the Container, and every connection to a resource manager used by an enterprise bean is obtained via the Container. This managed execution environment allows the Container to affect the enterprise bean’s transaction management.

This does not imply that the Container must interpose on every resource manager access performed by the enterprise bean. Typically, the Container interposes only on the resource manager connection factory (e.g. a JDBC data source) JNDI look up by registering the container-specific implementation of the resource manager connection factory object. The resource manager connection factory object allows the Container to obtain the javax.transaction.xa.XAResource interface as described in the JTA specification and pass it to the transaction manager. After the set up is done, the enterprise bean communicates with the resource manager without going through the Container.

16.7.1 Bean-managed transaction demarcation

This subsection defines the Container’s responsibilities for the transaction management of enterprise beans with bean-managed transaction demarcation.

Note that only Session and Message-driven beans can be used with bean-managed transaction demarcation. A Bean Provider is not allowed to provide an Entity bean with bean-managed transaction demarcation.

The Container must manage client invocations to an enterprise bean instance with bean-managed transaction demarcation as follows. When a client invokes a business method via the enterprise bean’s remote or home interface, the Container suspends any transaction that may be associated with the client request. If there is a transaction associated with the instance (this would happen if the instance started the transaction in some previous business method), the Container associates the method execution with this transaction.

The Container must make the javax.transaction.UserTransaction interface available to the enterprise bean’s business method or onMessage method via the javax.ejb.EJBContext interface and under the environment entry java:comp/UserTransaction. When an instance uses the javax.transaction.UserTransaction interface to demarcate a transaction, the Container must enlist all the resource managers used by the instance between the begin() and com- mit()—or rollback()— methods with the transaction. When the instance attempts to commit the transaction, the Container is responsible for the global coordination of the transaction commit[23].

In the case of a stateful session bean, it is possible that the business method that started a transaction completes without committing or rolling back the transaction. In such a case, the Container must retain the association between the transaction and the instance across multiple client calls until the instance commits or rolls back the transaction. When the client invokes the next business method, the Container must invoke the business method in this transaction context.

[23]The Container typically relies on a transaction manager that is part of the EJB Server to perform the two-phase commit across all the enlisted resource managers. If only a single resource manager is involved in the transaction and the deployment descriptor indicates that a resource manager local transaction may be used, the Container may use the local transaction optimization.

Sun Microsystems Inc

If a stateless session bean instance starts a transaction in a business method, it must commit the transaction before the business method returns. The Container must detect the case in which a transaction was started, but not completed, in the business method, and handle it as follows:

•Log this as an application error to alert the system administrator.

•Roll back the started transaction.

•Discard the instance of the session bean.

•Throw the java.rmi.RemoteException to the client.

If a message-driven bean instance starts a transaction in the onMessage method, it must commit the transaction before the onMessage method returns. The Container must detect the case in which a transaction was started, but not completed, in the onMessage method, and handle it as follows:

•Log this as an application error to alert the system administrator.

•Roll back the started transaction.

•Discard the instance of the message-driven bean.

The actions performed by the Container for an instance with bean-managed transaction are summarized by the following table. T1 is a transaction associated with a client request, T2 is a transaction that is currently associated with the instance (i.e. a transaction that was started but not completed by a previous business method).

The following items describe each entry in the table:

•If the client request is not associated with a transaction and the instance is not associated with a transaction, or if the bean is a message-driven bean, the container invokes the instance with an unspecified transaction context.

•If the client is associated with a transaction T1, and the instance is not associated with a transaction, the container suspends the client’s transaction association and invokes the method with