IM NTU Distributed Information Systems 2004 Distributed Transactions -- 1 Distributed Transactions Yih-Kuen Tsay Dept. of Information Management National.

IM NTUIM NTU

Distributed Information Systems Distributed Information Systems 20042004 Distributed TransactionsDistributed Transactions -- -- 11

Distributed Transactions

Yih-Kuen Tsay

Dept. of Information Management

National Taiwan University

IM NTUIM NTU

Distributed Information Systems Distributed Information Systems 20042004 Distributed TransactionsDistributed Transactions -- -- 22Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

Structures of Distributed Transactions

IM NTUIM NTU


• Both types of transaction invoke operations in more than one server.

• A flat transaction accesses servers’ objects sequentially.

• The subtransactions of a nested transaction can run in parallel (concurrently).

Flat vs. Nested Transactions

IM NTUIM NTU


Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

* The four subtransactions can run in parallel.

A Nested Banking Transaction

IM NTUIM NTU


* A transaction identifier may include the server identifier and a serial number.

A Distributed Banking Transaction

IM NTUIM NTU


Atomic Commitment inFlat Transactions

• When a distributed flat transaction comes to an end, either all or none of its operations (in different servers) are carried out.

• If one part of a transaction for some reasons (e.g., server crash, failure of validation) has to abort, then the whole transaction must also be aborted.

IM NTUIM NTU


The Two-Phase Commit Protocol

• A participant (server) is allowed to abort its part of a transaction (even after performing all operations).

• In the first phase, each server votes for the transaction to be committed or aborted.

• In the second phase, every server carries out the joint decision.

• The protocol tolerates server crashes or message losses.

IM NTUIM NTU



* A participant is prepared to commit when it has recorded the changes and

its status in permanent storage.

The Two-Phase Commit Protocol (cont.)

IM NTUIM NTU




IM NTUIM NTU




IM NTUIM NTU


Atomic Commitment inNested Transactions• When a subtransaction completes, it makes an ind

ependent decision either to commit provisionally or to abort.

• A parent transaction may commit even if one of its child transactions has aborted.

• If a parent transaction aborts, then its subtransactions will be forced to abort.

• Subtransactions will not carry out a real commitment unless the entire nested transaction descides to commit.

IM NTUIM NTU



* A provisional commit is not backed up in permanent storage.

Deciding Whether to Commit

IM NTUIM NTU



Operations in Coordinator forNest Transactions

IM NTUIM NTU


Two-Phase Commit inNested Transactions• When a subtransaction provisionally commit

s, it reports its status and the status of its descendants to its parent.

• When a subtransaction aborts, it just reports abort to its parent.

• Eventually, the top-level transaction receives a list of all subtransactions (except the descendants of an aborted transaction) in the tree, together with the status of each.

IM NTUIM NTU



Two-Phase Commit inNest Transactions (cont.)

IM NTUIM NTU


(Flat) Two-Phase Commit Protocol

• The top-level coordinator sends canCommit? to all sub-coordinators in the provisional commit list.

• When a server receives a canCommit? ...– If it has provisionally committed substractions

• prepares those without aborted ancestors for commitment,

• aborts those with aborted ancestors, and • sends a Yes vote to the coordinator.

– Otherwise (it must have failed), sends a No vote.

IM NTUIM NTU



The canCommit? Operation forTwo-Phase Commit in Nested Transactions

IM NTUIM NTU


Concurrency Control inDistributed Transactions

• Each server applies concurrency control to its own objects.

• Every pair of transactions are serializable in the same order at all servers.

IM NTUIM NTU


Locking

• Each server maintains locks for its own objects.

• Locks cannot be released until the transaction has been committed or aborted at all servers.

• Distributed deadlocks might occur if different servers impose different orderings on transactions.

IM NTUIM NTU


Timestamp Ordering

• A globally unique transaction timestamp is issued by the top-level coordinator.

• All servers must agree on how the timestamps are ordered.

• Conflicts are resolved as each operation is performed.

IM NTUIM NTU


Optimistic Concurrency Control

• If only one transaction may perform validation at the same time, commitment deadlocks might occur.

Transaction T Transaction U

Read(A) at X

Write(A)

Read(B) at Y

Write(B)

Read(B) at Y

Write(B)

Read(A) at X

Write(A)

IM NTUIM NTU


Optimistic Concurrency Control (cont.)

• Parallel validation prevents commitment deadlocks.

• A parallel validation checks (among other things) conflicts between write operations of the transaction being validated against the write operations of other concurrent transactions.

IM NTUIM NTU


Optimistic Concurrency Control (cont.)

• To ensure that transactions at different servers are globally serializable, the servers may – conduct a global validation (checking if there is

a cyclic ordering) or – use the same globally unique transaction numb

er for the same transaction.

IM NTUIM NTU



An Interleaving of Three Transactions

IM NTUIM NTU


Distributed Deadlocks

• A cycle in the global wait-for graph (but not in any single local one) represents a distributed deadlock.

• A deadlock that is detected but is not really a deadlock is called a phantom deadlock.

• Two-phase locking prevents phantom deadlocks; autonomous aborts may cause phantom deadlocks.

IM NTUIM NTU



Distributed Deadlocks and Wait-For Graphs

IM NTUIM NTU



Local and Global Wait-For Graphs

IM NTUIM NTU


Edge Chasing

• Initiation: when a server notes that a transaction T starts waiting for another transaction U, which is waiting to access an object at another server, it sends a probe containing TU to the server of the object at which transaction U is blocked.

IM NTUIM NTU


Edge Chasing (cont.)

• Detection: receive probes and decide whether deadlock has occurred and whether to forward the probes.

When a server receives a probe TU and finds the transaction that U is waiting for, say V, is waiting for another object elsewhere, a probe TUV is forwarded.

• Resolution: select a transaction in the cycle to abort

IM NTUIM NTU



Probes for Detecting Deadlocks

IM NTUIM NTU



Independently Initiated Probes

IM NTUIM NTU



Probes Traveling Downhill

IM NTUIM NTU


Transaction Recovery

• Requirements: durability and failure atomicity• Specific goal: restore the server with the latest

committed versions of its objects.• Tasks of the recovery manager:

– Save objects in permanent storage (a recovery file)– Restore objects after a crash– Reorganize the recovery file and reclaim storage– Optional: be resilient to media failures

IM NTUIM NTU



Types of Entry in a Recovery File

IM NTUIM NTU


Two Approaches to the Use of Recovery Files• Logging

– Basic ideas: history of transactions, snapshots, …– Recovery of objects: forward or backward– Checkpointing

• Shadow versions– Basic ideas: map, shadow version, version store, …– Switching from the old map to the new map– Checkpointing

IM NTUIM NTU



Log for Banking Service

IM NTUIM NTU



Shadow Versions

IM NTUIM NTU



A Log for the Two-Phase Commit Protocol

IM NTUIM NTU


Recovery of the Two-Phase Commit Protocol

IM NTU Distributed Information Systems 2004 Distributed Transactions -- 1 Distributed Transactions Yih-Kuen Tsay Dept. of Information Management National.

Documents