Understanding Container-Managed Transactions

In an EJB with container-managed transactions (CMT), the EJB container sets the boundaries of the transactions. This simplifies application development because the EJB developer does not include code that begins, commits, and rolls back the transaction. Implicitly, the container begins a transaction immediately before an EJB method starts, and commits the transaction just before the method exits. Each method can be associated with a single transaction. Nested or multiple transactions are not allowed within a method. Container-managed transactions do not require all methods to be associated with transactions. When deploying a bean, you specify which of the bean's methods are associated with transactions by setting the transaction attributes in the EJB's deployment descriptor.

In an EJB with container-managed transaction, you must set the value of the <transaction-type> of the standard deployment descriptor ejb-jar.xml to the value Container. Here is an example:

<ejb-jar>
  <enterprise-beans>
    <session>
      ...
      <transaction-type>Container</transaction-type>
    </session>
  </enterprise-beans>
</ejb-jar>

Bean-managed transaction demarcation, on the other hand, is the programmatic approach in which the EJB code manages the transaction boundary (you'll learn this approach on Day 18). In developing enterprise applications, the container-managed transaction demarcation is the preferred approach of the J2EE platform for managing the transaction boundary. This allows applications to be more flexible and portable, and easier to develop, deploy, and maintain.

All EJB types can use container-managed transactions, but that is not true for bean-managed transactions. Entity beans must use container-managed transactions. Session and message-driven beans may use either container-managed transactions or bean-managed transactions. Figure 17.1 summarizes the taxonomy of the various transaction options available to each EJB type.

In Figure 17.1, you can see that an EJB with bean-managed transactions may choose to implement either Java Database Connectivity (JDBC) transactions or Java Transaction API (JTA) transactions. JDBC transactions involve the use of the java.sql.Connection interface (refer to Day 9, “Using JDBC to Connect to a Database”), whereas JTA transactions involve the use of the javax.transaction.UserTransaction interface (refer to Day 16). Again, the J2EE architecture strongly encourages the use of JTA transaction options.

Using JDBC in CMT

The following is an example of a business method in an EJB with CMT demarcation. The business method updates two databases using JDBC connections. The container provides transaction demarcation per the assembler.

public class MySessionEJB implements SessionBean {
   EJBContext ctx;
   public void methodA(...) {
      Connection conn;
      Statement stmt;
      conn = ...;
      stmt = conn.createStatement();
      // Perform some updates on conn. The Container
      // automatically enlists conn with the container-
      // managed transaction.
      stmt.executeQuery(...);
      // release connections
      conn.close();
   }
   ...
}

The preceding code uses no explicit transaction demarcation, such as commit() or rollback().

Using Isolation Levels with CMT

As you learned on Day 16, the isolation level describes the degree to which access to a resource manager can be controlled among concurrently executing transactions. Isolation level is resource manager–specific, and the J2EE architecture does not define an API for managing the isolation level. In EJB with bean-managed transactions, you set the transaction isolation level in the application code, or in programmatic fashion. Most resource managers require that all access to the resource manager within a transaction be done with the same isolation level.

For container-managed transactions, you set the transaction isolation level in the vendor-specific deployment descriptor, or in declarative fashion. For example, in the WebLogic Server environment, the <transaction-isolation> element of the weblogic-ejb-jar.xml deployment descriptor is used to set these values, which correspond to the constant values of the isolation level of the Connection interface (refer to the “Transaction Isolation Level” section on Day 16). The following code shows how you can set the value of the <transaction-isolation> tag to Serializable:

<weblogic-ejb-jar>
  <transaction-isolation>
   <isolation-level>Serializable</isolation-level>
     <method>
        <ejb-name>...</ejb-name>
        <method-intf>...</method-intf>
        <method-name>...</method-name>
        <method-params>...</method-params>
     </method>
  </transaction-isolation>
</weblogic-ejb-jar>

WebLogic passes this value to the underlying database. The behavior of the transaction depends on both on the EJB's isolation level setting and the concurrency control of the underlying database.

The container uses the transaction isolation level attribute as follows:

• Session beans, message-driven beans, and entity beans with bean-managed persistence (BMP): For each database connection used by the bean, the container sets the transaction isolation level at the start of each transaction.

• Entity beans with container-managed persistence (CMP): The classes generated by the application server manage transaction isolation. The application server responsibility is to control the isolation level according to the setting in its configuration files.