Database transactions and concurrency - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 452

Many enterprise applications store data that is critical to the company and its cus-
tomers. Consider, for example, how your bank stores your money. Harry Potter's
vault at Gringotts bank contains real gold galleons, but your money exists as fragile
1s and 0s in the bank's database. There are many things that your bank must do to
safeguard that data, and one of the most important is maintaining the integrity of
that data when it is simultaneously updated by multiple database transactions.
Enterprise applications almost always have multiple simultaneous users. Many
also have background tasks, which are triggered by schedulers or events received
from external systems. As a result, there are usually multiple transactions that are
simultaneously reading and updating the database. A major challenge faced by
enterprise application developers is that data can become inconsistent when it is
updated by multiple transactions simultaneously. Even though you might expect
the database to prevent this from happening, it is often the responsibility of the
application to maintain the consistency of the data.
This is the first of two chapters that describe how an application can handle
concurrent updates. In this chapter you will learn about the basic concurrency
mechanisms you can use to handle concurrent updates within a database transac-
tion, which don't involve user interactions. We describe three different concur-
rency mechanisms and how to use them in i BATIS/JDBC , JDO , and Hibernate
applications. In addition, you'll learn how an application can recover from a data-
base concurrency failure. The next chapter shows you how to handle concurrent
updates in long-running business transactions, which consist of multiple database
transactions and usually involve user interactions.
12.1 Handling concurrent access to shared data
The outcome of executing multiple transactions simultaneously must be the same
as executing them serially, that is, one after the other, but in random order. Math-
ematically speaking, if there are N transactions, then there are factorial( N )
equally valid outcomes. This means, for example, that in the Food to Go applica-
tion there are two valid outcomes of executing the Send Orders to Restaurant and
Cancel Order use cases simultaneously. One outcome is that the order is sent to
the restaurant and not canceled (because it has already been sent). The other
outcome is that the order should be canceled and not sent to the restaurant.
If neither the application nor the database ensures that the outcome of
executing multiple transactions simultaneously is the same as executing them
serially, then the database can become inconsistent and the application can
behave incorrectly. One common problem is lost updates, which occur when one