OCT Distributed Transaction1 Lecture 13: Distributed Transactions Notes adapted from Tanenbaum’s “Distributed Systems Principles and Paradigms”

Slides:



Advertisements
Similar presentations
CS542: Topics in Distributed Systems Distributed Transactions and Two Phase Commit Protocol.
Advertisements

COS 461 Fall 1997 Transaction Processing u normal systems lose their state when they crash u many applications need better behavior u today’s topic: how.
Copyright © George Coulouris, Jean Dollimore, Tim Kindberg This material is made available for private study and for direct.
Transactions Distributed Systems An introduction to Transaction Processing (TP), Two Phase Locking (2PL) and the Two Phase Commit Protocol.
Computer Science Lecture 18, page 1 CS677: Distributed OS Last Class: Fault Tolerance Basic concepts and failure models Failure masking using redundancy.
Transactions Distributed Systems An introduction to Transaction Processing (TP), Two Phase Locking (2PL) and the Two Phase Commit Protocol.
Consistency in distributed systems Distributed systems Lecture # 10 Distributed systems Lecture # 10.
Computer Science Lecture 12, page 1 CS677: Distributed OS Last Class Distributed Snapshots –Termination detection Election algorithms –Bully –Ring.
Systems of Distributed Systems Module 2 -Distributed algorithms Teaching unit 3 – Advanced algorithms Ernesto Damiani University of Bozen Lesson 6 – Two.
Computer Science Lecture 17, page 1 CS677: Distributed OS Last Class: Fault Tolerance Basic concepts and failure models Failure masking using redundancy.
Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Outline Introduction Background Distributed DBMS Architecture Distributed Database.
Atomic TransactionsCS-4513 D-term Atomic Transactions in Distributed Systems CS-4513 Distributed Computing Systems (Slides include materials from.
Chapter 7 Fault Tolerance Basic Concepts Failure Models Process Design Issues Flat vs hierarchical group Group Membership Reliable Client.
Distributed Systems CS Fault Tolerance- Part III Lecture 15, Oct 26, 2011 Majd F. Sakr, Mohammad Hammoud andVinay Kolar 1.
Atomic TransactionsCS-502 Fall Atomic Transactions in Distributed Systems CS-502, Operating Systems Fall 2007 (Slides include materials from Operating.
Transactions Distributed Systems Lecture 15: Transactions and Concurrency Control Transaction Notes mainly from Chapter 13 of Coulouris.
EEC 693/793 Special Topics in Electrical Engineering Secure and Dependable Computing Lecture 12 Wenbing Zhao Department of Electrical and Computer Engineering.
CSS490 Replication & Fault Tolerance
Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Outline Introduction Background Distributed DBMS Architecture Distributed Database.
1 More on Distributed Coordination. 2 Who’s in charge? Let’s have an Election. Many algorithms require a coordinator. What happens when the coordinator.
Distributed Commit. Example Consider a chain of stores and suppose a manager – wants to query all the stores, – find the inventory of toothbrushes at.
Distributed Systems Fall 2009 Distributed transactions.
Service Oriented Architecture Master of Information System Management Service Oriented Architecture Lecture 9 Notes from: Web Services & Contemporary.
Distributed Commit Dr. Yingwu Zhu. Failures in a distributed system Consistency requires agreement among multiple servers – Is transaction X committed?
CS162 Section Lecture 10 Slides based from Lecture and
Service Oriented Architecture Master of Information System Management Service Oriented Architecture Notes from: Web Services & Contemporary SOA.
Transactions Distributed Systems Introduction to Transaction Processing (TP) and the Two Phase Commit Protocol Notes adapted from: Coulouris:
Transaction Communications Yi Sun. Outline Transaction ACID Property Distributed transaction Two phase commit protocol Nested transaction.
Distributed Transactions Chapter 13
Distributed Systems CS Fault Tolerance- Part III Lecture 19, Nov 25, 2013 Mohammad Hammoud 1.
1 8.3 Reliable Client-Server Communication So far: Concentrated on process resilience (by means of process groups). What about reliable communication channels?
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
CSE 486/586 CSE 486/586 Distributed Systems Concurrency Control Steve Ko Computer Sciences and Engineering University at Buffalo.
TRANSACTIONS (AND EVENT-DRIVEN PROGRAMMING) EE324.
Distributed Transaction Management, Fall 2002Lecture Distributed Commit Protocols Jyrki Nummenmaa
Fault Tolerance CSCI 4780/6780. Distributed Commit Commit – Making an operation permanent Transactions in databases One phase commit does not work !!!
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Lecture 11 – Distributed Concurrency Management Tuesday Oct 5 th, Distributed Systems.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved Chapter 8 Fault.
More on Fault Tolerance Chapter 7. Topics Group Communication Virtual Synchrony Atomic Commit Checkpointing, Logging, Recovery.
Distributed Transactions Chapter – Vidya Satyanarayanan.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved Chapter 8 Fault.
Lampson and Lomet’s Paper: A New Presumed Commit Optimization for Two Phase Commit Doug Cha COEN 317 – SCU Spring 05.
Fault Tolerance Chapter 7.
Fault Tolerance. Basic Concepts Availability The system is ready to work immediately Reliability The system can run continuously Safety When the system.
 2002 M. T. Harandi and J. Hou (modified: I. Gupta) Distributed Transactions.
Consistency David E. Culler CS162 – Operating Systems and Systems Programming Lecture 35 Nov 19, 2014 Read:
A client transaction becomes distributed if it invokes operations in several different Servers There are two different ways that distributed transactions.
CS 162 Section 10 Two-phase commit Fault-tolerant computing.
Fault Tolerance Chapter 7. Basic Concepts Dependability Includes Availability Reliability Safety Maintainability.
TRANSACTION & CONCURRENCY CONTROL 1. CONTENT 2  Transactions & Nested transactions  Methods for concurrency control  Locks  Optimistic concurrency.
Fault Tolerance Chapter 7. Goal An important goal in distributed systems design is to construct the system in such a way that it can automatically recover.
Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Outline Introduction Background Distributed DBMS Architecture Distributed Database.
More on Fault Tolerance
Atomic Transactions in Distributed Systems
CSC 8320 Advanced Operating Systems Xueting Liao
Distributed Systems Learning Objectives
Distributed Systems An introduction to Transaction Processing (TP) and the Two Phase Commit Protocol Notes adapted from: Coulouris: Distributed.
Transactions and Concurrency Control
Distributed Systems CS
Distributed Systems CS
Distributed Systems CS
CSE 486/586 Distributed Systems Concurrency Control --- 3
Lecture 09 – Distributed Concurrency Management
Distributed Systems Lecture 09 – Distributed Concurrency Management Tuesday Sept 29th, 2016.
Distributed Systems CS
UNIVERSITAS GUNADARMA
CSE 486/586 Distributed Systems Concurrency Control --- 3
Last Class: Fault Tolerance
Transaction Communication
Presentation transcript:

OCT Distributed Transaction1 Lecture 13: Distributed Transactions Notes adapted from Tanenbaum’s “Distributed Systems Principles and Paradigms”

OCT Distributed Transaction2 Hypothetical Web Service Transaction Begin transaction BookTrip book plane book hotel book rental car End transaction BookTrip

OCT Distributed Transaction3 Transactions (ACID) Atomic: All or nothing. No intermediate states are visible. Consistent: system invariants preserved, e.g., if there were n dollars in a bank before a transfer transaction then there will be n dollars in the bank after the transfer. Isolated: Two transactions do not interfere with each other. They appear as serial executions. Durable: The commit causes a permanent change.

OCT Distributed Transaction4 Client talks to coordinator BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client openTrans Unique Transaction ID TID Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. TID = openTransaction() Recoverable objects needed to rent a car. Any server

OCT Distributed Transaction5 Client calls methods BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. Call + TID plane.bookFlight(111,”Seat32A”,TID) Any server Recoverable objects needed to rent a car.

OCT Distributed Transaction6 BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. Object informs participant The participant knows where the coordinator is because that information can be included in the TID (eg. an IP address.) The coordinator now has a pointer to the participant. The participant only calls join if it has not already done so. join(TID,ref to participant)

OCT Distributed Transaction7 BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. Suppose all goes well (1) OK returned Recoverable objects needed to rent a car.

8 BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. Suppose all goes well (2) OK returned CloseTransaction(TID) Called Coordinator begins 2PC and this results in a GLOBAL COMMIT sent to each participant. Recoverable objects needed to rent a car.

9 BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. This time no cars available (1) OK returned NO CARS AVAIL abortTransaction(TID) called Recoverable objects needed to rent a car.

10 BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. This time no cars available (2) OK returned NO CARS AVAIL abortTransaction(TID) called Coordinator sends a GLOBAL_ABORT to all particpants Recoverable objects needed to rent a car.

11 BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client ROLLBACK CHANGES This time no cars available (3) OK returned NO CARS AVAIL abortTransaction(TID) abortTransaction Each participant Gets a GLOBAL_ABORT ROLLBACK CHANGES

OCT Distributed Transaction12 BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. BookPlane Server Crashes after returning ‘OK’ (1) OK returned Recoverable objects needed to rent a car.

13 BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. BookPlane Server Crashes after returning ‘OK’ (2) OK returned CloseTransaction(TID) Called Coordinator excutes 2PC: Ask everyone to vote. No news from the BookPlane Participant so multicast a GLOBAL ABORT Recoverable objects needed to rent a car.

14 BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane ROLLBACK BookPlane Server Crashes after returning ‘OK’ (3) OK returned CloseTransaction(TID) Called ROLLBACK GLOBAl ABORT ROLLBACK

OCT Distributed Transaction15 Two-Phase Commit Protocol BookTrip Coordinator BookPlane BookHotel BookRentalCar Phase 1 BookTrip coordinator sends a Vote_Request to each process. Each process returns a Vote_Commit or Vote_Abort. Vote_Request Vote Request Vote_Commit Vote Commit

16 Two-Phase Commit Protocol (Gray BookTrip Coordinator BookPlane BookHotel BookRentalCar Phase 2 BookTrip coordinator checks the votes. If every process votes to commit then so will the coordinator. In that case, it will send a Global_Commit to each process. If any process votes to abort the coordinator sends a GLOBAL_ABORT. Each process waits for a Global_Commit message before committing its part of the transaction. Global Commit ACK Global Commit ACK Global Commit ACK

OCT Distributed Transaction17 2PC Finite State Machine from Tanenbaum Init wait Abort Commit Vote-request Vote-commit Global-commit Vote-abort Global-abort Init Ready Abort Commit Vote-request Vote-commit Vote-request Vote-abort Global-commit ACK Global-abort ACK State has already been saved to permanent storage. BookTrip CoordinatorParticipant

OCT Distributed Transaction18 2PC Blocks in three places Init wait Abort Commit Vote-request Vote-commit Global-commit Vote-abort Global-abort Init Ready Abort Commit Vote-request Vote-commit Vote-request Vote-abort Global-commit ACK Global-abort ACK If waiting too long for a Vote-Request send a Vote-Abort

OCT Distributed Transaction19 2PC Blocks in three places Init wait Abort Commit Vote-request Vote-commit Global-commit Vote-abort Global-abort Init Ready Abort Commit Vote-request Vote-commit Vote-request Vote-abort Global-commit ACK Global-abort ACK If waiting too long After Vote-request Send a Global-Abort

OCT Distributed Transaction20 2PC Blocks in three places Init wait Abort Commit Vote-request Vote-commit Global-commit Vote-abort Global-abort Init Ready Abort Commit Vote-request Vote-commit Vote-request Vote-abort Global-commit ACK Global-abort ACK If waiting too long we can’t simply abort! We must wait until the coordinator recovers. We might also make queries on other participants.

OCT Distributed Transaction21 2PC Blocks in three places Init wait Abort Commit Vote-request Vote-commit Global-commit Vote-abort Global-abort Init Ready Abort Commit Vote-request Vote-commit Vote-request Vote-abort Global-commit ACK Global-abort ACK If this process learns that another has committed then this process is free to commit. The coordinator must have sent out a Global-commit that did not get to this process.

OCT Distributed Transaction22 2PC Blocks in three places Init wait Abort Commit Vote-request Vote-commit Global-commit Vote-abort Global-abort Init Ready Abort Commit Vote-request Vote-commit Vote-request Vote-abort Global-commit ACK Global-abort ACK If this process learns that another has aborted then it too is free to abort.

OCT Distributed Transaction23 2PC Blocks in three places Init wait Abort Commit Vote-request Vote-commit Global-commit Vote-abort Global-abort Init Ready Abort Commit Vote-request Vote-commit Vote-request Vote-abort Global-commit ACK Global-abort ACK Suppose this process learns that another process is still in its init state. The coordinator must have crashed while multicasting the Vote-request. It’s safe for this process (and the queried process) to abort.

OCT Distributed Transaction24 2PC Blocks in three places Init wait Abort Commit Vote-request Vote-commit Global-commit Vote-abort Global-abort Init Ready Abort Commit Vote-request Vote-commit Vote-request Vote-abort Global-commit ACK Global-abort ACK Tricky case: If the queried processes are all still in their ready state what do we know? We have to block and wait until the Coordinator recovers.