So response time to end-users is one important measure of TP system performance. No one likes waiting more than a few seconds for an automated teller machine to dispense cash or for a hotel web site to accept a reservation request. Performance is a critical aspect of TP systems. Using two-phase commit adds overhead (due to two-phase commit messages), but the option to distribute can provide better scalability (adding more systems to increase capacity) and availability (since one system can fail while others remain operational). Thus, one key question that designers of TP applications must answer is whether or not to distribute their transaction programs among multiple resources. Two -phase commit is required whenever a transaction accesses two or more resource managers. The details of how two-phase commit handles all these scenarios is described in Chapter 8. For example, in Figure 1.7(b), it must tell the London system to commit the transaction. However, to make this all work, the protocol must handle every possible failure and recovery scenario. Therefore, even if a system fails during the commitment activity, as the London system did in the figure, it can commit the transaction after it recovers. Two -phase commit avoids the problem in Figure 1.7(a) because all resource managers have a durable copy of the transaction's updates before any of them commit. " Thus, all resource managers have durably stored the transaction's updates before any of them commits in phase two. In Phase One, every resource manager durably saves the transaction's updates before replying " I am Prepared. Figure 1.9 gives an example execution of two-phase commit with two resource managers involved.įIGURE 1.9 The Two-Phase Commit Protocol. So it sends a second round of messages to tell the resource managers to actually commit. That is, it knows that all resource managers stored a durable copy of the transaction's updates but none of them have committed the transaction. When the transaction manager gets acknowledgments back from all the resource managers, it knows that the whole transaction has been prepared. At this point, the resource managers are said to be prepared to commit. In the first round of messages it tells all the resource managers to prepare to commit by writing a copy of the results of the transaction to stable storage, but not actually to commit the transaction. When running two-phase commit, the transaction manager sends out two rounds of messages - one for each phase of the commitment activity. Thus, each resource manager must understand the concept of transaction, in the sense that it undoes or permanently installs the transaction's updates depending on whether the transaction aborts or commits. Similarly, if the transaction manager receives an abort operation, it tells the resource managers to undo all the transaction's updates that is, to abort the transaction at each resource manager. When a transaction program finishes execution and issues the commit operation, that commit operation goes to the transaction manager, which processes the operation by executing the two-phase commit protocol. This is important because when it comes time to commit the transaction, the transaction manager has to know all the resource managers to talk to in order to execute the two-phase commit protocol.
Whenever the transaction accesses a new resource manager, somebody has to tell the transaction manager. This requires some cooperation with the application, resource managers, and communication system. During the execution of the transaction, it keeps track of all the resource managers that the transaction accesses. When an application issues a Start operation, the transaction manager dispenses a unique ID for the transaction called a transaction identifier. Typically, there's one transaction manager on each node of a distributed computer system. The transaction manager is primarily a bookkeeper that keeps track of transactions in order to ensure atomicity when more than one resource is involved. It calls Abort to tell the transaction manager to abort the transaction. It calls Commit to ask the transaction manager to commit the transaction. An application calls Start to begin executing a new transaction. The transaction manager processes the basic transaction operations for applications: Start, Commit, and Abort. Printed with permission from Morgan Kaufmann, a division of Elsevier.
This is an excerpt from Principles of Transaction Processing by Philip Bernstein and Eric Newcomer.
0 kommentar(er)
