Chapter 12. Transactions

Understanding Transactions

Transactions are at the heart of business applications, and the support the EJB container provides for them arguably tops the list of J2EE's benefits. You've gotten an introduction to transactions within EJB in earlier chapters, but now it's time to look at the details. The goal of this chapter is to explain some of the concepts behind transactional processing and equip you with what you need to know to build EJB applications that execute transactions correctly.

A transaction is a general business concept that represents an exchange between two parties. When you walk into a department store and purchase a shirt, you're exchanging some form of payment for an item sold by the store. The exchange that takes place defines the boundaries of a sales transaction. Both your payment to the salesperson and the act of the salesperson giving you the shirt make up the transaction. If either action were to happen without the other, the transaction wouldn't be valid and the sale would never occur.

The principal characteristic of a transaction is that it groups individual actions together into a single activity that has greater significance. The idea is that relatively small actions can take on more meaning when they're viewed as part of some bigger picture. Grouping actions into transactions this way is part of everyday life. It's such an everyday occurrence, you probably don't spend much time thinking about it. You participate in a transaction every time you shop at a store, make a reservation with an airline, visit an ATM, or perform countless other exchanges. The fact that transactions are so much a part of the real world makes it a given that they show up in the software that models parts of the real world, too.

Software applications that address business problems of any complexity must support the concept of transactions because an application is useful only if it accurately reflects the nature of the business it models. When looking at anything from high-level business logic down to low-level communications protocols, software is continually relied on to execute operations that must be performed as a set for the outcome to have any validity. No matter what type of programming you do, transactions are important to you.

For a desktop application that manipulates data stored by the local file system or a local database, a transaction is relatively easy to support. The single user of the system performs some operations that are either applied to the underlying data or they're not. Some level of error handling and undo functionality are needed, but overall it's not too difficult a program to build. It's when a single transaction needs to be applied to distributed applications that access multiple databases and other resources that the true complexity of reliable transaction processing comes into play. That's the topic of the most interest to an EJB developer.

No matter what the size or complexity of an application, every transaction associated with it has a definite beginning and end. The process of establishing these boundaries is known as transaction demarcation and it is central to managing transactions. Any operations that occur between the boundaries of a transaction become associated with that transaction and are treated as a single unit of work. The effects of a transaction, which most often consist of updates to the contents of one or more databases, are made permanent by committing the transaction at its completion. The effects of a transaction must also be capable of being undone by a process known as rolling back the transaction before it has been committed. A transaction ends when either a commit or a rollback occurs.

The difficulty in implementing transactions in complex software systems is that changes to multiple resources must be coordinated so that commits and rollbacks are performed across all affected components of a system. It's also necessary to coordinate the work being done by multiple users accessing a system's shared data concurrently. Each of these is enough of a challenge when everything works as anticipated, but it's even more true when errors occur along the way. Of course, this is when transactions are the most beneficial. If failures never occurred, there would never be a need to roll back the effects of a transaction. It's when something does go wrong that transactional support makes it possible for the integrity of a system to be maintained .

This chapter looks at how J2EE application servers and EJB containers do much of the work required to handle distributed transactions for you. From your perspective as a developer, it's important that you understand what's being done for you by the container and what your role is. The EJB architecture removes you from much of the complexity of transaction management, but how you code and deploy your enterprise beans still determines how they can be used in a transactional application.