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

transaction blindly overwrites another transaction's changes. Both transactions
think they have updated the database even though one transaction's changes have
been lost. A lost update in the Food to Go application could, for example, cause a
restaurant to prepare an unwanted order. If it were a bank, money could
disappear, which is something that couldn't happen to the gold at Gringotts—at
least not without magic!
Another common problem are inconsistent reads, which occur when the data
being read by one transaction is updated by another transaction. The transaction
that is reading the data sees different values at different times, which can result in
incorrect behavior. This can potentially happen any time an application queries
the same data more than once. It can also happen when a transaction uses multi-
ple queries to load related data, such as an order and its line items. In between
two queries another transaction could change the data. For more information
about lost updates and inconsistent reads, as well as some more subtle problems,
see Transaction Processing: Concepts and Techniques [Gray 1993].
There are three main ways to handle concurrent accesses to shared data. Let's
look at each one in turn.

12.1.1 Using fully isolated transactions

One solution is to use transactions that are fully isolated from one another, which
in database-speak are transactions with an isolation level of serializable. The data-
base ensures that the outcome of executing multiple serializable transactions is
the same as executing them serially. Serializable transactions prevent such prob-
lems as lost updates and inconsistent reads. For more information about serializ-
able transactions and the nuances of how they are supported by different
databases, see [Gray 1993] or the documentation for your database.
As you will see later, using serializable transactions is very straightforward. You
configure Spring, JDO , or Hibernate, or the JDBC DataSource , to use the serializ-
able isolation level. The database tries to execute the transactions serially, and if it
cannot because of a problem (such as a deadlock), it will return an error code.
The application can then roll back and retry the failed transaction.
Serializable is only one of the transaction isolation levels provided by data-
bases. Some databases also provide a repeatable read isolation level, which, as the
name suggests, ensures that a transaction gets the same results each time it reads a
row. However, unlike serializable transactions, repeatable read transactions can
get inconsistent results when they execute a query because other transactions can
insert and delete rows, which are known as phantoms.