Sun Microsystem Inc

Container Provider responsibilities

Enterprise JavaBeans v1.1, Final Release

Support for Transactions

11.6 Container Provider responsibilities

This section defines the responsibilities of the Container Provider.

Every client method invocation on an enterprise Bean object via the bean’s remote and home interface 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 the resource manager connection factory (e.g. a JDBC API data source) JNDI API 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 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.

11.6.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 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 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 commit()—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[11].

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.

[11]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.

173

11/24/99

Sun Microsystems Inc.

Support for Transactions

Enterprise JavaBeans v1.1, Final Release

Container Provider responsibilities

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.

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).

Table 6	Container’s actions for methods of beans with bean-managed transaction
			Transaction currently	Transaction associated
		Client’s transaction	associated with instance	with the method
		none	none	none
		T1	none	none
		none	T2	T2
		T1	T2	T2

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, 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 an unspecified transaction context. The container resumes the client’s transaction association (T1) when the method completes.

•If the client request is not associated with a transaction and the instance is already associated with a transaction T2, the container invokes the instance with the transaction that is associated with the instance (T2). This case can never happen for a stateless Session Bean.

•If the client is associated with a transaction T1, and the instance is already associated with a transaction T2, the container suspends the client’s transaction association and invokes the method with the transaction context that is associated with the instance (T2). The container resumes the client’s transaction association (T1) when the method completes. This case can never happen for a stateless Session Bean.

11/24/99

174