Course Title: Distributed Computing Assigned by: Sir Nazir Ahmad

Distributed Transaction
A distributed transaction is a transaction that updates data on two or more networked computer systems. Distributed transactions extend the benefits of transactions to applications that must update distributed data. Implementing robust distributed applications is difficult because these applications are subject to multiple failures, including failure of the client, the server, and the network connection between the client and server. In the absence of distributed transactions, the application program itself must detect and recover from these failures.

For distributed transactions, each computer has a local transaction manager. When a transaction does work at multiple computers, the transaction managers interact with other transaction managers via either a superior or subordinate relationship. These relationships are relevant only for a particular transaction. Each transaction manager performs all the enlistment, prepare, commit, and abort calls for its enlisted resource managers (usually those that reside on that particular computer). Resource managers manage persistent or durable data and work in cooperation with the DTC to guarantee atomicity and isolation to an application. In a distributed transaction, each participating component must agree to commit a change action (such as a database update) before the transaction can occur. The DTC performs the transaction coordination role for the components involved and acts as a transaction manager for each computer that manages transactions. When committing a transaction that is distributed among several computers, the transaction manager sends prepare, commit, and abort messages to all its subordinate transaction managers. In the two-phase commit algorithm for the DTC, phase one involves the transaction manager requesting each enlisted component to prepare to commit; in phase two, if all successfully prepare, the transaction manager broadcasts the commit decision. In general, transactions involve the following steps: 1. Applications call the transaction manager to begin a transaction. 2. When the application has prepared its changes, it asks the transaction manager to commit the transaction. The transaction manager keeps a sequential transaction log so that its commit or abort decisions will be durable.
o

If all components are prepared, the transaction manager commits the transaction and the log is cleared. If any component cannot prepare, the transaction manager broadcasts an abort decision to all elements involved in the transaction.

While a component remains prepared but not committed or aborted, it is in doubt about whether the transaction committed or aborted. If a component or transaction manager fails, it reconciles in-doubt transactions when it reconnects.

When a transaction manager is in-doubt about a distributed transaction, the transaction manager queries the superior transaction manager. The root transaction manager, also referred to as the global commit coordinator, is the transaction manager on the system that initiates a transaction and is never in-doubt. If an in-doubt transaction persists for too long, the system administrator can force the transaction to commit or abort.

How Distributed Transactions Work

The DTC supports transactions that are distributed across two or more Microsoft Windows 95 or Windows 2000 or later systems. Each system has a local transaction manager. All applications and resource managers communicate with their local transaction managers. The transaction managers cooperatively manage transactions that span systems. When a request arrives with a new transaction, a superior-subordinate relationship is established between the two systems. Usually the transaction manager on the system making the request becomes superior to the transaction manager on the system receiving the request. The idea behind the superior-subordinate relationship is that the superior system drives all the systems subordinate to it using the two-phase commit protocol. Each system can have many systems subordinate to it but can have at most one superior. These superior and subordinate relationships form a tree of relationships called the transaction's commit tree.

The enlisted resource managers are also members of this commit tree. They usually have a subordinate relationship to their local transaction manager. The superior and subordinate relationships are relevant only for a particular transaction. That is, transaction manager A can be the superior to transaction manager B on a particular transaction while functioning as a subordinate to transaction manager B on a different transaction. When a distributed transaction commits or aborts, the prepare, commit, and abort messages flow outward on the commit tree. Any node of the tree can unilaterally abort a transaction at any time before it agrees to the prepare request sent in the first phase. After a node has prepared, it remains prepared and in-doubt until the commit coordinator tells it to commit or abort the transaction. The root transaction manager of the commit tree is called the global commit coordinator. This coordinator makes the decision to either commit or abort the transaction and is never in doubt. If a computer fails and then restarts, the transaction manager at that computer tries to determine the outcome of all in-doubt transactions in which it participated. The local transaction manager reads its log file to determine the outcomes of transactions for which it was the commit coordinator and takes one of the following actions: 1. If it has a superior transaction manager, the local transaction manager determines whether it was previously notified of the outcome of the transaction by the superior transaction manager. 2. If the local transaction manager is in-doubt regarding a particular transaction, it queries its superior to learn the transactions outcome. The transaction manager also responds to queries from subordinate transaction managers regarding in-doubt transactions, similar to the protocol that transaction managers and resource managers follow at restart. The transaction manager determines the outcome of each in-doubt transaction and informs the resource managers of the transaction's outcome. System or communication failures can leave transactions in-doubt for extended periods of time. While a transaction is in-doubt, the resources modified by the transaction remain locked and unavailable to others. The system administrator can use the Component Services administrative tool to resolve transactions that remain in-doubt.

Application Programmer's View of Transactions

The application programmer's transaction model is simpleprograms either succeed or fail. When the application program begins a transaction, it gets a transaction object. All subsequent work is associated with that transaction object. When the program reaches a consistent state, it calls the Commit method. If the commit succeeds, the transaction is durably committed. If the

commit fails, the transaction aborts. If the application program can't successfully complete the transaction, it can call the Abort method to undo the transaction's effects. If the program fails before it commits the transaction, the transaction manager aborts the transaction and informs each enlisted resource manager to rollback the transaction's effects. If either the computer or resource manager fails, the transaction is also aborted. If the transaction successfully commits, the resource managers and the transaction manager ensure that the transaction's effects are durable, even if there are subsequent failures.

Resource Manager's Role in Transactions

The resource manager registers itself with the local transaction manager and then waits for execution requests from an application program. When a request arrives with a new transaction object, the resource manager enlists in the transaction by invoking the Enlist method. By enlisting, the resource manager ensures that it gets callbacks from the transaction manager when the transaction commits or aborts. The resource manager then performs the transaction's requests. For example, the transaction might insert, delete, or update records in a relational database. The resource manager retains enough information to enable it to either undo or redo the transaction for example, by storing multiple versions of the data or keeping a log of the changes. When the application program commits the transaction, the transaction manager initiates the two-phase commit protocol. The transaction manager first requests each enlisted resource manager to prepare to commit the transaction. The resource manager prepares to commit by storing enough state durably to either commit or abort the transaction. Typically, the old and new data is recorded in stable storage so that the resource manager can recover it even if the system fails. If the resource manager cant prepare successfully, it informs the transaction manager that it cant prepare and the transaction manager aborts the transaction. If the resource manager can prepare, it informs the transaction manager that it is prepared and then awaits the transaction manager's decision on whether to commit or abort the transaction. After it is prepared, a resource manager must wait until it gets a commit or abort request from the transaction manager. The entire prepare and commit protocol typically completes within a fraction of a second. However, a system or communication failure could delay the commit or abort notification for several minutes or even hours. During this period, the resource manager is in-doubt about the outcome of the transaction; it doesn't know whether the transaction committed or aborted. While the resource manager is in-doubt about the transaction, it locks the data modified by the transaction, isolating these changes from any other transactions. When a resource manager fails, all of its enlisted transactions are aborted, except those that prepared or committed prior to the failure. When the resource manager restarts, it queries the transaction manager about the outcome of the in-doubt transactions in which it enlisted. The

transaction manager tells the resource manager the outcome of each in-doubt transaction, and the resource manager commits or aborts these transactions accordingly. The DTC helps resource managers make transactions atomic and durable when a resource manager fails and then restarts. The resource manager must reconstruct the committed state of the resources it manages, reflecting all of the effects of committed transactions and none of the effects of aborted transactions.

Transaction Manager's Role in Transactions

The transaction manager creates transaction objects and manages their atomicity and durability. Applications request the creation of a transaction object by calling the transaction manager's BeginTransaction method. When a resource manager first participates in a transaction, it calls the Enlist method to enlist in the transaction. The transaction manager tracks all the resource managers who enlist in the transaction. One of the following three results can occur: 1. The application either commits or aborts the transaction. 2. A resource manager aborts the transaction. 3. A failure occurs. The Commit and Abort methods can also be called on transaction objects. When asked to commit a transaction, the transaction manager initiates the two-phase commit protocol. During the first phase, it asks all enlisted resource managers to prepare. During the second phase, the transaction manager informs the resource managers whether the transaction committed or aborted. The transaction manager maintains a log in storage on disk. The log is a sequential file that records transaction events. The transaction manager records transaction starts, enlistments, and commits decisions in the log. During normal processing, the transaction manager only writes to the log. However, if the transaction manager fails, it reads the log when it restarts to reconstruct the most recent state, using the log to make its state durable.

Commit Coordination
The DTC uses the presumed abort two-phase commit protocol optimization. That is, if an enlisted transaction participant asks the DTC about a transaction and the DTC has no information, the enlisted participant assumes that the transaction has aborted. The DTC also supports the following two-phase commit optimizations:

Read-Only Commit Optimization

Delegated Commit Optimization

Read-Only Commit Optimization

The DTC permits resource managers that can read but cannot update transaction-protected data to reply "read-only" at phase one. In this case, the transaction manager does not deliver the second phase notification to the resource manager. The read-only optimization is also used between transaction managers to optimize the commitment of whole subtrees of the transaction tree. A transaction manager replies "read-only" if all of the resource managers and transaction managers subordinate to it reply "read-only." This signifies that this transaction manager and the entire subtree it controls need not receive notification at phase two of commit. Using this optimization eliminates the need for certain log writes and also allows for earlier release of locks on some resources.

Delegated Commit Optimization

The DTC permits commit coordinator responsibility to be delegated from the coordinating transaction manager to one of its subordinate transaction managers or resource managers. Commit coordinator delegation occurs when the coordinating transaction manager detects that only one subordinate resource manager or transaction manager is enlisted in the transaction. The coordinating transaction manager delegates commit coordinator responsibility to the resource manager when both of the following two conditions are true:
1. No subordinate transaction manager is enlisted in the transaction. 2. Only one resource manager is enlisted in the transaction.

In this case, the coordinating transaction manager sets fSinglePhase when invoking the ITransactionResourceAsync::PrepareRequest method at phase one. This instructs the resource manager that it should act as the transaction coordinator. The DTC delegates commit coordinator responsibility to the subordinate transaction manager when both of the following two conditions are true:
1. No resource manager is enlisted in the transaction with the current coordinating transaction manager. 2. Only one subordinate transaction manager is enlisted in the transaction.

In this case, the coordinating transaction manager sends a "delegated commit" message in place of the phase one message. The "delegated commit" message transfers commit coordinator responsibility from the current coordinating transaction manager to its subordinate transaction manager. This optimization is applied recursively. A transaction manager that receives commit coordinator responsibility may delegate commit coordinator responsibility to its subordinate

transaction manager or resource manager. Using this optimization eliminates the need for certain log writes and also allows for earlier release of locks on some resources.

Transaction Propagation
A transaction begun in one process can be propagated to another process. Resource managers built on a client/server architecture have a server side and a client side. The server side enlists in a transaction so that it can participate in the two-phase commit. However, because the DTC transaction might have been initiated on the client side, client/server resource managers use a DTC-implemented mechanism to propagate a transaction from the client side to the server side. To propagate a transaction, the resource manager proxy on the client side provides a function that an application can call to request a resource manager to enlist in a transaction. After obtaining the transaction to enlist in, the resource manager proxy uses ITransactionExport to propagate the transaction to the transaction coordinator.
To export a transaction

1. The application client obtains an ITransaction interface by invoking the ITransactionDispenser::BeginTransaction method. 2. The application client calls the IResourceManager2::Enlist2 method, passing it the transaction in which it wants the resource manager to enlist. 3. Within the IResourceManager2::Enlist2 method, the resource manager proxy does the following:
o

Invokes ITransactionExport::Export, passing it the ITransaction interface provided by the client. (See Obtaining the Whereabouts of the Participating DTC for information about how to obtain the ITransactionExport interface. If the preceding step succeeds, the resource manager proxy obtains the transaction cookie by invoking ITransactionExport::GetTransactionCookie. The resource manager proxy sends the transaction cookie to the resource manager via a communication pipe that is used for the transmission of all messages between the proxy and the resource manager server.

After the resource manager server receives the transaction cookie, it invokes ITransactionImport::Import, providing it with the cookie that it received from its proxy. This invocation translates the cookie to an ITransaction interface, and if it succeeds, the resource manager has an interface to the client-initiated transaction.