Building a Pick List

Managing Transactions

As discussed in Chapter 12, "Transactions," it's expected that most EJBs you write will be involved in performing transactional work. This usually means that your EJBs will be accessing and updating shared data in a relational database. The transactional support provided by the EJB container does most of the work of managing transactions for you, but there are a couple of points to keep in mind that can affect the performance of your applications. You need to be sure that your transactions are being demarcated at the necessary boundaries and that the resource locking that's being enforced isn't excessive.

Transaction Demarcation

When you deploy an entity bean, you should usually specify a transaction attribute of Required for the bean's business methods . You might have some special needs that make one of the other attributes more appropriate, but those situations are rare. When you use the Required attribute, all updates to an entity object take place within a transaction that can be rolled back if necessary. You always need to define the transactional requirements for your entity beans, but it's usually redundant because they're being accessed by session beans on behalf of clients . If a session bean method is executed within the context of a transaction, the same transaction is associated with any entity bean methods it calls that have a transaction attribute of Required (or Supports ). This is the way to package work done by a session bean method into an atomic unit of work.

Application behavior changes from what's been described so far if a session bean method is executed without an associated transaction or it accesses entity bean methods deployed with the RequiresNew attribute. In either of these scenarios, a new transaction is started and committed every time an entity bean method is called. This creates a lot of overhead that is sure to slow an application. However, performance isn't so much the driver of the point being made here, as it is the indicator of a problem. If a call to a session bean method results in multiple transactions as entity bean methods are executed, the work being done cannot be rolled back as a single unit if there's a problem. If you're suffering from performance problems due to transactional overhead, you need to first be sure that your transaction boundaries are being established correctly.

Isolation Level

Chapter 12 introduced the read uncommitted, read committed, repeatable read, and serializable isolation levels that can be used to control concurrent access to resources. Using the serializable isolation level protects an application from erroneous results by preventing a transaction from accessing any data being manipulated by another in-progress transaction. This is an important trait for critical operations, but it does impact performance. The locking done to support this isolation level slows concurrent access to a resource so you should limit this level of protection to the parts of your application that actually require it.

For more information on isolation levels, see "Isolating Access to Resources," p. 359 .