Chapter 10. Understanding Transactions

The EJB architecture provides for two kinds of transaction demarcation: container-managed transaction demarcation and bean-managed transaction demarcation. This chapter covers the essential aspects of transactions a typical application developer needs to know.

With the container-managed transaction demarcation approach, the EJB container does the bulk of the work of managing transactions for the programmer. This greatly simplifies the application developer's work when programming transactional applications. However, even though the container does the majority of the work, the bean provider or application assembler must still provide transaction-related instructions to the container. Part of this chapter explains how the example entity bean application described in Chapter 8 uses transaction attributes, which are special attributes set in the deployment descriptor to instruct the container on how to manage transactions for the benefits application.

This chapter also discusses bean-managed transaction demarcation. With this approach, the bean developer manages transaction boundaries programmatically from within the application code. The Benefits Enrollment application does not use bean-managed transaction demarcation. Instead, we discuss appropriate scenarios for using bean-managed transaction demarcation.

Application programmers benefit from developing their applications on platforms that support transactions. A transaction-based system simplifies application development because it frees the developer from the complex issues of failure recovery and multiuser programming. In addition, the EJB architecture does not limit transactions to single databases or single sites but rather supports distributed transactions that can simultaneously update multiple databases across multiple sites.

How is this accomplished? The EJB architecture permits the work of an application to, typically, be divided into a series of units. Each unit of work is a separate transaction. While the application progresses, the underlying system ensures that each unit of work each transaction fully completes without interference from other processes. If not, the system rolls back the transaction, completely undoing whatever work the transaction had performed.

The EJB architecture allows enterprise beans to use a declarative style of transaction management that differs from the traditional transaction management style. With declarative management, the enterprise bean application declares transaction attributes in the deployment descriptor. These transaction attributes explain how to partition the work of an application into separate, discrete units of work. The transaction attributes indicate to the container how it should apply transaction management to the execution of the bean's methods.

Using the traditional transaction management approach, the application was responsible for managing all aspects of a transaction. This entailed such operations as

• Explicitly starting the transaction

• Committing or rolling back the transaction

• Suspending and resuming the transaction association, particularly for applications that need more sophisticated transaction demarcation

A developer must have more programming expertise to write an application that is responsible for managing a transaction from start to finish. The code for such an application is more complex, and thus more difficult to write, and it is easy for "pilot error" to occur; for example, a programmer may forget to commit a transaction. Furthermore, it is difficult to reuse components that programmatically manage transaction boundaries as building blocks for applications with additional components.

With declarative transaction management, the container manages most, if not all, aspects of the transaction for the application. The container handles starting and ending the transaction and maintains its context throughout the life of the transaction. The container automatically propagates the transaction context into invoked enterprise beans and resource managers, based on the declarative instructions in the deployment descriptor. This greatly simplifies an application developer's responsibilities and tasks, especially for transactions in distributed environments. In addition, it means that the components are reusable as building blocks for other applications composed of multiple components.