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

RequiresNew

The container always creates a new transaction before invoking the enterprise bean method and commits the transactions when the method returns. If the calling client is not associated with a transaction context, container will automatically begin a new transaction and try to commit the transaction when the method completes. If the calling client is associated with a transaction context, the container suspends the association of the transaction context with the current thread before starting the new transaction. When the method and the transaction complete, the container resumes the suspended transaction.

Figure 2 Transaction propagation in RequiresNew

NotSupported

Figure 3 Transaction propagation in NotSupported

If the transaction attribute is NotSupported, the transactional context of the calling client is not propagated to the enterprise bean. If a client calls with a transaction context, the container suspends the client's transaction association before invoking the enterprise bean's method. After the method completes, the container resumes the suspended transaction association.

NotSupported in message driven beans:

The container invokes a message-driven bean method with its transaction attribute set to NotSupported with an unspecified transaction context. If the onMessage method invokes other enterprise beans, the Container passes no transaction context with the invocation.

Supports

Figure 4 Transaction propagation in Supports

It the transaction attribute is Supports, and the client is associated with a transaction context, the context is propagated to the enterprise bean method, like the way the container treats the Required case. If the client call is not associated with any transaction context, the container behaves similarly to the NotSupported case. The transaction context is not propagated to the enterprise bean method.

Mandatory

Figure 5 Transaction propagation in Mandatory

The transaction attribute Mandatory requires the container to invoke a bean's method in a client's transaction context. If the client is not associated with a transaction context when calling this method, the container throws javax.transaction.TransactionRequiredException. If the calling client has a transaction context, the case is treated as Required by the container.

Never

Figure 6 Transaction propagation in Never

The transaction attribute Never requires that the enterprise bean method not be called within a transaction context. If the client calls with a transaction context, the container throws the java.rmi.RemoteException. If the client is not associated with any transaction context, the container invokes the method without initiating a transaction.

If an enterprise bean implements the javax.ejb.SessionSynchronization interface, only the following values for the transaction attributes of the bean's methods can be specified: Required, RequiresNew,, or Mandatory.

This restriction is necessary to ensure that the enterprise bean is invoked only in a transaction. If the bean were invoked without a transaction, the container would not be able to send the transaction synchronization calls. The tools used by the application assembler can determine if the bean implements the javax.ejb.SessionSynchronization interface, for example, by using the Java reflection API on the enterprise bean's class.

The enterprise bean's business methods or onMessage method must not use any resource manager specific transaction management methods that would interfere with the container's demarcation of transaction boundaries. For example, the enterprise bean methods must not use the following methods of the java.sql.Connection interface: commit(), setAutoCommit(), and rollback(). It must not use the following methods of the javax.jms.Session interface: commit() and roll-back(). The enterprise bean's business methods or onMessage method must not attempt to obtain or use the javax.transaction.UserTransaction interface.

An enterprise bean with container-managed transaction demarcation can use the setRollbackOnly() method of its EJBContext object to mark the transaction so that the transaction can never commit. Typically an enterprise bean marks a transaction for rollback to protect data integrity before throwing an application exception because they don't automatically cause the container to rollback the transaction. Such a bean can also use the getRollbackOnly() method of its EJBContext object to test if the current transaction has been marked for rollback.

Deployment descriptor declaration

The bean provider of a session bean or a message-driven bean must use the transaction-type element to declare whether the session bean or message-driven bean is of the bean-managed or container-managed transaction demarcation type. The transaction-type element is not supported for entity beans because all entity beans must use container-managed transaction demarcation. The bean provider of an enterprise bean with container=managed transaction demarcation may optionally specify the transaction attributes for the enterprise bean's methods.

This section shows examples of deployment descriptors for specifying transaction attributes for methods of home and remote interfaces of session and entity beans and onMessage methods of message-driven beans. The container-transaction element is used to define transaction attributes. Each container-transaction element consists of a list of one or more method elements and the transattribute element which specifies that all the listed methods are assigned the specified transaction attribute value. All the methods specified in a single container-transaction element be must be methods of the same enterprise bean. The method element uses the ejb-name, method-name, and method-params elements to denote one or more methods of an enterprise bean's home and remote interfaces. There are three legal formats of composing the method element:

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

Pages: 1, 2, 3, 4

Next Page