1 / 10

Understanding Distributed Transactions: Models, Protocols, and Recovery Mechanisms

Distributed transactions involve multiple servers and require robust models to handle network unreliability and asynchronous communication. Key objectives include consistency, fault tolerance, performance, and availability. This overview details transaction models like nested transactions and protocols such as the One-Phase Commit and Two-Phase Commit, highlighting the roles of coordinators and participants. It also addresses challenges like distributed deadlock detection and recovery procedures, emphasizing the necessity for all-or-nothing semantics and proper logging to maintain transaction integrity during failures.

adria-jensen
Télécharger la présentation

Understanding Distributed Transactions: Models, Protocols, and Recovery Mechanisms

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Distributed Transactions March 15, 2001

  2. Transactions • What is a Distributed Transaction? • A transaction that involves more than one server • Network can be unreliable, asynchronous • Need a failure model that is practical • e.g., System R design • Objectives: Consistency, Fault-Tolerance, Performance, Availability

  3. Transactions, cont. • Transaction Model • Use nested transactions • One coordinator for each top-level or nested transaction • Failure model • Asynchronous communication (e.g., unreliable network) • Servers may fail unexpectedly • No bugs that cause servers to send the wrong message at the wrong time • Byzantine failures can kill performance

  4. Transactions, cont. • Example One-Phase Commit Protocol • Coordinator sends commit/abort requests to all participants • Wait until you hear back • Timeout (or a similar mechanism) and try again if you don't hear back • No unilateral decision - commit needs to finish once it starts, even if there is a system failure • One issue: Failures can lead to long wait times

  5. Transactions, cont. • Two Phase Commit • Any participant can request a transaction commit/abort • Transaction must be aborted if 1 participant aborts • Phase I - Vote • A “commit” vote means that participants can carry out the commit if told to • Save process state in non-volatile storage (enhanced crash recovery) • Phase II - Carry out the decision • To commit, every participant must vote “commit” • Timeouts help get around lost messages

  6. Transactions, cont. • Two Phase Commit, Nested Transactions • Commit can occur even if all participants do not vote for commit • More sophisticated coordination needed • Hierarchic • Voting is done hierarchically, along the nested transaction tree • Flat • Top-level coordinator gets votes directly from all coordinators who have provisionally committed • Also need an abort list

  7. Transactions, cont. • Distributed Deadlock • Centralized detection • Performance issues • False positives (e.g., Phantom Deadlocks) • To help prevent deadlocks, use two-phase locking

  8. Transactions, cont. • Recovery • Need all or nothing semantics • For each transaction being processed, track: • Object values • Intentions list - <object id, where I can find object value> • Transaction status (e.g., prepared, committed, aborted)

  9. Transactions, cont. • Logging For Simple Transactions • Keep one log file that records updates • e.g., Each time transaction code modifies a locked object, log the new value • To prepare to commit, move relevant logged items to recovery manager • e.g., objects in intentions list, intentions list, transaction status • Transaction state change recorded by recovery manager (prepared, aborted, committed) • Transactions not committed to the recovery manager are aborted upon a crash

  10. Transactions, cont. • Distributed Recovery from two-phase commit • Two new transaction states - done (server state), uncertain (client state) • Phase I - uncertain (client voted Yes) • Phase II - done (transaction complete - optional)

More Related