Database Reference
In-Depth Information
across multiple systems. In order to continue to honor the ACID properties of transactions, you
now need a transaction manager to orchestrate across the multiple nodes.
In order to account for successful completion across multiple hosts, the idea of a two-phase com-
mit (sometimes referred to as “2PC”) is introduced. But then, because two-phase commit locks
all associate resources, it is useful only for operations that can complete very quickly. Although
it may often be the case that your distributed operations can complete in sub-second time, it is
certainly not always the case. Some use cases require coordination between multiple hosts that
you may not control yourself. Operations coordinating several different but related activities can
take hours to update.
Two-phase commit blocks; that is, clients (“competing consumers”) must wait for a prior trans-
action to finish before they can access the blocked resource. The protocol will wait for a node to
respond, even if it has died. It's possible to avoid waiting forever in this event, because a timeout
can be set that allows the transaction coordinator node to decide that the node isn't going to
respond and that it should abort the transaction. However, an infinite loop is still possible with
2PC; that's because a node can send a message to the transaction coordinator node agreeing that
it's OK for the coordinator to commit the entire transaction. The node will then wait for the
coordinator to send a commit response (or a rollback response if, say, a different node can't com-
mit); if the coordinator is down in this scenario, that node conceivably will wait forever.
So in order to account for these shortcomings in two-phase commit of distributed transactions,
the database world turned to the idea of compensation. Compensation, often used in web ser-
vices, means in simple terms that the operation is immediately committed, and then in the event
that some error is reported, a new operation is invoked to restore proper state.
There are a few basic, well-known patterns for compensatory action that architects frequently
have to consider as an alternative to two-phase commit. These include writing off the transaction
if it fails, deciding to discard erroneous transactions and reconciling later. Another alternative
is to retry failed operations later on notification. In a reservation system or a stock sales ticker,
these are not likely to meet your requirements. For other kinds of applications, such as billing or
ticketing applications, this can be acceptable.
NOTE
Gregor Hohpe, a Google architect, wrote a wonderful and often-cited blog entry called “Starbucks
Does Not Use Two-Phase Commit.” It shows in real-world terms how difficult it is to scale two-
phase commit and highlights some of the alternatives that are mentioned here. Check it out at
ht-
tp://www.eaipatterns.com/ramblings/18_starbucks.html
.
It's an easy, fun, and enlightening read.
