J2EE Design Patterns

Chapter 10. Enterprise Concurrency

The most dramatic difference between an enterprise system and a “regular” application is the number of users it must serve. As a result, enterprise applications face problems that don’t often occur on the desktop. A word processor, for example, doesn’t have to handle two users making changes to one paragraph at the same time—at the most, it might have to notify the second user that the document is already in use.

Of course, all data-centric applications, whether they serve one user or 10,000, need to concern themselves with the validity of their data. An action that seems simple to the user (“Order a book”) may require complex, choreographed activities within the application (“Check inventory, reserve stock, charge credit cards, arrange shipping, etc.”). The more operations an application performs, the more likely one of those activities will fail—and when it does, the system must be able to carry on. Providing for this capability is easy in standalone applications: just don’t save your changes if the mail merge fails. But if other users have been modifying the same databases at the same time, the brute-force approach to data integrity won’t pan out.

A lot of ink has been spilled on these issues. Since we’re always eager to help, we’ve coined a new term for an old concept: enterprise concurrency . Enterprise concurrency has two elements: transaction management and concurrency management. Transaction management, abstracted to a high level, controls ...