3.4 The Distributed Transaction Coordinator

To represent DTC, I use a cartoon figure of a wise woman in a Zen meditative state who sees everything happening around her and is not distracted by the flotsam of life. You need this kind of focus to implement DTC's demanding algorithms. Meet DTC in Figure 3.3.

Figure 3.3. Introducing DTC, the Distributed Transaction Coordinator

DTC manages the tightly coupled multiple-resource transaction by creating a higher-level supertransaction that oversees transactions at the resource (database) level.

From a software system perspective, tightly coupled multiple-resource transactions using DTC look identical to tightly coupled single-resource transactions. In both cases, we issue a BeginTransaction request, a bunch of Update requests , and a Commit request. Then, magically, either the entire bunch is processed or none of the bunch is processed . However, to coordinate the transaction across the various databases, DTC takes a direct role in managing the transaction.

DTC can find herself in any of four states, each with different algorithmic responsibilities. Her states, and the conditions under which she moves from one to the other, are as follows .

The first state is the sleep state. This is DTC's default state. Vacation state. The state she stays in when there is nothing better for her to do.

When somebody issues the BeginTransaction request, DTC transitions from the sleep state to the meditative state. In the meditative state she starts paying attention to which databases are getting Update requests. When she notices a database ”say, Database A ”getting its first Update request, she makes a mental note that Database A is part of this transaction. This is when she needs her full Zen focusing powers. If even one database update sneaks past her, the whole algorithm will fall apart.

When we issue the Commit request, DTC transitions from the meditative state to the consensus state. She assumes that the transaction has concluded and starts trying to achieve consensus among the involved databases as to whether the transaction should be accepted or rejected in its entirety. To do this, she asks each database in turn if it would be willing to accept its portion of the updates. Each database gives her an answer but holds its updates in a state of limbo until hearing further from DTC.

When DTC gets an answer from the last database that had been part of this transaction, she transitions from the consensus state into the final state. What she does in the final state depends on the answers she got from the various databases in the consensus state. If they all indicated a willingness to accept the updates, she goes back to each database and tells each to "commit" the changes. If any database in the consensus state indicated an unwillingness, or even a mild trepidation, about accepting its updates, then in this final state DTC tells all the databases to forget the whole deal and discard their update requests.

When DTC has told the last database what to do, she transitions from the final state back into the sleep state. DTC's state transitions are shown in Figure 3.4.

Figure 3.4. DTC's States

You might think that DTC has the last word in transactional coordination, combining the best capabilities of single-resource transactions (tight coordination) with the best capabilities of multiple-resource transactions (no restrictions as to the number of players). For all her charm , however, DTC has her own set of problems.

Her first problem is communication. She needs to know how to chat with the databases. If she can't have the discussions with the databases that are required in the consensus and final states, she can't orchestrate this algorithm. Her ability to coordinate is dependent, therefore, not just on her willingness to work with the databases, but on the databases' willingness to work with her.

DTC's second problem is performance. She needs not just to communicate with the databases, but to communicate frequently. Even worse , most of this communication requires synchronous protocols. The dependence on synchronous communication protocols means that the rest of the world (including the rest of the databases that DTC is coordinating) is blocked, waiting for her expensive communications to complete.

To see the relative cost of the three approaches to transactions ”tightly coupled single-resource, loosely coupled multiple-resource, and tightly coupled multiple-resource ”consider the checking account update described in this chapter. Remember, this example involved a balance read, a balance update, and an activity log. I'll consider three cases. In Case 1, shown as a SAD (sequence “allydiagram) in Figure 3.5, both accounts and activity logs exist in a single database (single resource, tightly coupled). In Case 2, shown as a SAD in Figure 3.6, accounts and activity logs are separated into two loosely coupled databases. In Case 3, shown as a SAD in Figure 3.7, accounts and activity logs again are separated into two databases, but now the databases are tightly coupled, so DTC is involved.

Figure 3.5. SAD for a Tightly Coupled Single-Resource Transaction

Figure 3.6. SAD for a Loosely Coupled Multiple-Resource Transaction

Figure 3.7. SAD for a Tightly Coupled Multiple-Resource Transaction

The SADs for the three types of transactions show how much more communication is required for the tightly coupled multiple-resource case. The SADs also show how much of that additional communication is synchronous. It's pretty SAD.