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

These bean definitions ensure that any call to RestaurantNotificationService is
retried if a ConcurrencyFailureException is thrown. When the RestaurantNotifi-
cationService is invoked, the TransactionRetryInterceptor is called first, which
then calls the TransactionInterceptor to manage the transactions. The Transac-
tionInterceptor then calls the actual RestaurantNotificationService .
It is important to remember that you can only retry a transaction if all the work
done inside the transaction can be undone and repeated. The transaction cannot
be automatically rolled back and retried if the application calls nontransactional
API s such as a legacy system, or does things that can't be undone, such as sending
email. Recovering from concurrency failures in these kinds of situations can be a
challenging problem, one that must be solved by application-level code. Fortu-
nately, rolling back and retrying a transaction isn't a problem if the application
only updates the database or calls API s such as JMS .
12.5 Summary
An application can handle concurrent updates to shared data in one of three
ways. One option is to use serializable transactions, which are transactions that are
completely isolated from one another. Alternatively, you can use pessimistic or
optimistic locking. An important benefit of serializable transactions is that each
transaction has a consistent view of the data and the database prevents one trans-
action from overwriting another's changes. Also, they do not involve any extra
coding; you just have to configure Spring, the JDBC DataSource , or the persistence
framework. However, serializable transactions have a high overhead and thus per-
formance is lower. Furthermore, they are suited to short transactions that update
only a few rows.
Because of the overhead of serializable transactions, many applications use a
read committed isolation level along with either pessimistic or optimistic locking.
A transaction that uses pessimistic locking locks rows when they are read. Other
transactions are prevented from updating those rows and, in some cases, from
reading them. A transaction that uses optimistic locking doesn't lock the rows but
instead verifies that the rows it's about to update are unchanged since they were
read. Optimistic locking can detect changes using a version or a timestamp col-
umn or by comparing columns.
If you are using i BATIS or JDBC , then you must implement optimistic locking or
pessimistic locking yourself. In comparison, JDO and Hibernate have built-in sup-
port for optimistic locking and pessimistic locking and automatically generate the
required SQL statements. You enable optimistic locking for a class by configuring its