J2EE Design Patterns

Transaction Management

Here’s a common situation that arises in enterprise development: you need to perform a set of actions as if they were a single action.^[1] In real life, the simplest transactions take place within one resource, such as a database, and within a very short period of time. A bank transaction implemented by changing values for a particular field in two different rows of a table, via two update statements executed one after the other, is a simple transaction. You don’t want to record the value of one update without the other. Even if the chance of something interfering—money automatically being deducted to pay a bill between the two updates, for instance—is small, it’s a chance that can’t be taken. To make life even more exciting, the odds of something going wrong increase dramatically when you start coordinating the transaction across space (multiple databases, messaging systems, EJBs, etc.) and time (multiple user requests to a web application).

Complex activities call for complex transactions. Let’s take the ubiquitous stock-trading system example: for a brokerage firm to execute a buy order, it must charge a user’s account, execute the trade, and send various confirmation messages. The confirmation messages shouldn’t be sent without the trade, the account shouldn’t be charged without the trade, and the trade shouldn’t be executed without confirmations being sent. Each activity in the chain might involve a different system or technology, yet the entire process ...