Transaction Semantics for CMT

The J2EE architecture describes semantics that govern transaction-processing behavior based on the EJB type (entity bean, stateless session bean, or stateful session bean) and the transaction type (container-managed or bean-managed). These semantics describe the transaction context at the time a method is invoked, and define whether the EJB can access methods in the javax.transaction.UserTransaction interface. EJB applications must be designed with these semantics in mind. For container-managed transactions, transaction semantics vary for each bean type. The following sections discuss these transaction semantics with respect to each EJB type.

Implementing Session Beans with CMT

Stateless session beans can be pooled together and reused by different users. The duration of a container-managed transaction is tightly coupled with the duration of a single method call.

Because stateful session beans are not shared between multiple users, they are not transactional by design. Member variables (or the bean's state) cannot be rolled back when a transaction aborts. On the other hand, session beans can propagate transaction context to other resources they interface with, such as a database or a Java Message Service (JMS) queue. Only beans that manage their own transactions have access to the UserTransaction via the EJBContext. EJBs that do not manage their transaction can access only the setRollbackOnly() and getRollbackOnly() methods of the EJBContext. In a stateful session bean, the life cycle of a container-managed transaction is not tightly coupled with the life cycle of the EJB.

Synchronizing the State of a Session Bean

The EJB architecture allows stateful session beans to optionally synchronize their state. This is accomplished by implementing the SessionSynchronization interface (in the package javax.transaction). The EJB container notifies the EJB with the beginning and end of a transaction demarcation through the callback methods of the SessionSynchronization interface. Any information that might have been cached in its state by the EJB can be committed when the transaction completes. In addition, in the case of a rollback, a stateful session bean might want to refresh any required instance variables of its state from the database because the container will not perform this automatically.

Use of the SessionSynchronization interface by an stateful session bean implies the implementation of the callback methods afterBegin(), beforeCompletion(), and afterCompletion(). Figure 17.3 summarizes the life cycle of a stateful session bean implementing the SessionSynchronization interface. Refer to Day 6 for more details about stateful session beans.

The afterBegin() method is called by the container after a new transaction is started but before the business method is invoked, so it's a good place to synchronize the instance variables of the session bean with the state of the database. The session bean also has a chance to roll back in the beforeCompletion() method. In the afterCompletion() method, the session bean can check whether a rollback occurred and respond accordingly. The following example demonstrates the use of the SessionSynchronization interface with the stateful session bean MyStatefulEJB:

public class MyStatefulEJB implements SessionBean, SessionSynchronization {
    private SessionContext ctx;
    private boolean isFailed = false;
...
    public void afterBegin() {}

    public void beforeCompletion() {
       if ( isFailed ) {
           ctx.setRollbackOnly();
       }
    }
    public void afterCompletion(boolean success) {
        if (!success)
        //rollback occurred
    }
...
}

In the preceding example, the afterCompletion() method indicates that the transaction has completed. It has a single boolean parameter, success, whose value is true if the transaction was committed and false if it was rolled back. If a rollback occurs, the session bean can refresh its instance variables from the database in the afterCompletion() method.

Methods Not Allowed in CMT

As a general rule, you shouldn't invoke any method that might interfere with the transaction boundaries set by the container. Table 17.2 summarizes the methods that JB developers should avoid calling while developing an EJB with CMT.

Bean-managed transactions do not have these restrictions. You may, however, use these methods to set boundaries in bean-managed transactions. For more information about bean-managed transaction, see Day 18.

Message-Driven Beans with CMT

The EJB architecture allows message-driven beans (MDBs) with CMT to use either the Required or the NotSupported transaction attribute:

• Required: The EJB container automatically starts a transaction, and a message receipt from a JMS queue or topic is included in the transaction. The onMessage() method is called automatically by the container within this transaction context. When onMessage() returns, the EJB container automatically commits the transaction. If the transaction fails, the message stays in the queue until it is delivered to the message-driven bean. The container handles message acknowledgement automatically on behalf of the MDB.

• NotSupported: The EJB container does not start a transaction before calling onMessage(). MDBs rely on message acknowledgement mechanisms used by the JMS provider. Refer to Day 13, “Understanding JMS and Message-Driven Beans,” for more information about JMS.

Entity Beans

Entity beans are always container-managed. The ejbLoad() callback method loads the current state of an entity row from the database. The ejbStore() method updates the current state onto the database. Because an entity bean is a proxy representation of a table row in a database, the ejbLoad() method is the first method that a container calls in a transaction, and ejbStore() is the last method called before the end of a transaction. The business methods are called inbetween. An entity bean cannot be a bean-managed transaction because a bean cannot call either ejbLoad() or ejbStore() method to synchronize its state.

Summary of Transaction Options for EJBs

Table 17.3 lists the types of transactions that are allowed for the different types of EJBs. An entity bean must use container-managed transactions. With container-managed transactions, you specify the transaction attributes in the deployment descriptor, and you roll back a transaction with the setRollbackOnly() method of the EJBContext interface.

Setting WebLogic-Specific Transactions

Because our examples use WebLogic, we must discuss a few parameters in respect to WebLogic transactions. The following sections describe how to set these parameters in the vendor-specific deployment descriptor weblogic-ejb-jar.xml.

Setting Transaction Timeouts

An EJB developer can specify the timeout period for transactions in enterprise applications. If the duration of a transaction exceeds the specified timeout setting, the transaction manager rolls back the transaction automatically. In a bean-managed transaction, this is done programmatically in the code. The transaction timeout is set before the transaction begins. See Day 18 for more information about bean-managed transactions.

In container-managed transactions, the EJB developer sets the transaction timeout in the vendor-specific deployment descriptor. For WebLogic, the <trans-timeout-seconds> tag of the weblogic-ejb-jar.xml deployment descriptor is used:

<weblogic-ejb-jar>
   <transaction-descriptor>
       <trans-timeout-seconds>5<trans-timeout-seconds>
   </transaction-descriptor>
</weblogic-ejb-jar>

Only EJBs with container-managed transactions are affected by the <trans-timeout-seconds> attribute. For EJB with BMT, you invoke the setTransactionTimeout() method of the UserTransaction interface (in JTA transactions).