Handling Transactions in EJBs

Almost every EJB application uses transactions at some point. Transactions ensure atomicity and reliability and are essential for Web-based applications. Because transactions are expensive within the server, misusing them significantly affects performance. Many EJB applications limit their performance by making their transactions too fine-grained, hence causing problems if they span too many operations. In reality, transactions should never rely on user input. Your application will not be scalable if you start a transaction and wait for a user to complete the form or click Submit on a Web form. In fact, it is best to avoid handling transactions in the Web tier all together. JSP/servlets should be concerned with presentation logic and use an interface to communicate with the business logic. Transactional business logic should be handled within the EJB layer .

Regardless of the underlying concurrency strategy, transactions acquire locks and use many server resources. For example, if a user starts a transaction and then goes to lunch or even visits another Web site, the transaction is not committed until it times out. Instead, the transaction continues to hold valuable locks and resources within the server until the transaction times out. Unless there is a business reason for doing so, transactions should not last for more than 5 “10 seconds. In addition, the transaction demarcation should occur inside the server. The following sections discuss well-known techniques to avoid keeping long-running transactions open .

Use Container Managed Transactions Instead of Bean Managed Transactions

The EJB specification enforces a restriction that entity beans cannot participate in Bean-Managed Transactions (BMT). However, it does allow session beans to choose BMT or Container-Managed Transactions (CMT). In CMT, the bean developer defines transaction attributes in the deployment descriptor. The EJB container then automatically starts and commits transactions as requested . The bean developer does not have to deal with managing transactions. In BMT, the bean developer uses the javax.transaction.UserTransaction interface to control transaction boundaries.

The benefit of this approach is that the bean developer has full control over starting and rolling back transactions. The developer has to start a transaction by issuing a begin statement and complete the transaction by issuing a commit or rollback statement.

As discussed earlier, transactions consume a lot of resources in the application server and in databases. That is why keeping transactions as short as possible is always a recommended practice.

CMT encompasses a set of method calls. When the outer method finishes, the transaction is committed or rolled back by the container. In BMT, the bean developer must ensure that the transaction is committed or rolled back. Although the transaction manager imposes a default transaction timeout, the bean writer should not rely on this feature, but instead release transactional resources as soon as possible. With BMT, the bean writer needs to ensure that every exceptional path handles the transaction rollback or commit correctly. The EJB container automatically issues rollbacks or commits for CMT.

However, you might need to use BMT in the following two situations:

• You define multiple transactions from within a single method call. WebLogic Server demarcates transactions on a per-method basis.

  Tip

  However, instead of using multiple transactions in a single method call, it is better to break the method into multiple methods, with each of the multiple methods having its own CMT.

  
  

• You define a single transaction that spans multiple EJB method calls. For example, you define a stateful session EJB that uses one method to begin a transaction, and another method to commit or roll back the transaction.

  Caution

  Implementing separate methods to initiate and commit or rollback requires detailed information about the working internals of an EJB object.

  
  

CMT should always be the bean developer's first choice.

Do Not Use the Supports Transaction Attribute

The valid transaction attributes are Never , NotSupported , Supports , Required , RequiresNew , or Mandatory . In general, the Supports attribute should not be used for enterprise-wide applications. The risk of using the Supports attribute is that the EJBs run in a transaction only if the caller has started a transaction. If you have a business reason to run a method call in a transaction, use Required , RequiresNew , or Mandatory ; if you do not need transactional behavior, use Never or NotSupported .

Consider Using the Mandatory Transaction Attribute

Many EJB programmers deploy their beans with the Required transaction attribute. This attribute works in many cases because it inherits the caller's transaction if one exists; otherwise , Required starts its own transaction. As explained earlier, developers must understand how transaction attributes can affect performance. A new programmer on your team might be reusing the Employee entity bean and mistakenly call every getXXX method in an individual transaction. One way to prevent this is to deploy your entity bean with the Mandatory transaction attribute. Unlike Required , a Mandatory bean does not start its own transaction. If it is called with a transaction, the Mandatory bean participates in that transaction. If a Mandatory bean is called without a transaction, the EJB container immediately throws an exception to the caller. Deploying entity beans with the Mandatory transaction attribute is an easy way to indicate that the operations should be grouped together in a calling transaction.

Consider Using Transactional DataSources for Entity Beans

If you configure a JDBC DataSource factory for use with entity beans, make sure you configure a transactional DataSource ( TxDataSource ) rather than a non-transactional DataSource ( DataSource ). With a non-transactional DataSource, the JDBC connection operates in auto commit mode, committing each insert and update operation to the database immediately, instead of as part of a CMT.

Always Demarcate Transactions at the WLS or Database Level

In general, client applications are not guaranteed to stay active over long periods of time. If a client begins a transaction and then exits before committing, it wastes valuable transaction and connection resources in WebLogic Server. Moreover, even if the client does not exit during a transaction, the duration of the transaction might be unacceptable if it relies on user activity to commit or roll back data. Demarcating transactions at the WebLogic Server or relational database management system (RDBMS) level when possible is the recommended practice.